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

Abstract

【課題】予約の際のユーザの作業負担を軽減する機能を提供する。
【解決手段】ユーザの使用に係る端末装置と通信可能な予約支援装置において、端末装置における入力の内容を解析する。その解析結果に応じて所定の内容を応答する。所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断し、予約に必要な情報が充足されていないと判断された場合には、必要な情報の入力を促す内容を応答する。端末装置において、画像の選択によって情報の入力が可能な機能が付加された画像が表示され、この画像の選択によって情報の入力が行われた場合には、この入力の内容を解析し、予約支援装置にて解析可能な内容に変換する。
【選択図】図１

Description

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

従来の予約システムは、特定のフォームにユーザが必要事項をすべて入力し、サーバに送信することで予約の申込みを行っていた。例えばゴルフ場予約の場合、各ゴルフ場の予約情報を参照してプランや空き枠の情報を自ら確認し、そのうえで所定のフォームに移行して予約申し込みを行うことになる（例えば、特許文献１）。

特開２００５−０８４７９７号公報

しかし、例えばチャットのように対話形式で行われるサービスによって、コンピュータと対話しながら予約を行うシステムを用いる場合においては、一般的に文字情報のやり取りの仕組みとなっているため、ゴルフ場を検索する場合も、都道府県をテキストで入力する必要がある。これがユーザにとっては大変煩雑な操作であった。
本発明は、この点に鑑みてなされたものであり、チャットのように対話形式で行われるサービスによって、コンピュータと対話しながら予約を行うシステムを用いる場合において、予約の際のユーザの作業負担を軽減する機能を提供することなどを解決課題とする。

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

上述した課題を解決するため、本発明に係る予約支援システムは、ユーザの使用に係る端末装置（２a）と、当該端末装置（２a）と通信可能な予約支援装置（１a）とを備える予約支援システムであって、前記予約支援装置（１a）は、前記端末装置（２a）における入力の内容を解析する解析部（１０）と、前記解析部（１０）における解析結果に応じて所定の内容を応答する応答部（１１）と、所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断する判断部（１２）と、前記判断部（１２）により前記予約に必要な情報が充足されていないと判断された場合に、前記必要な情報の入力を促す内容を前記応答部（１１）により応答させる応答制御部（１３）と、前記判断部（１２）により前記予約に必要な情報が充足されたと判断された場合に、前記予約に必要な情報を登録する登録部（１４）とを備え、前記端末装置（２a）は、画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部（２１）と、前記ユーザによる操作に応じて、前記取得部（２１）で取得された前記画像を表示させる表示制御部（２３）と、前記ユーザによる操作に応じて情報を入力可能な入力部（２２）と、前記入力部（２２）を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記解析部（１０）により解析可能な内容に変換する変換部（２４）とを備えることを特徴とする。

この発明において、所定のアクティビティに関する予約は、スポーツ、音楽、映画、演劇、食事、宿泊等、あらゆるアクティビティに関する予約を含む概念である。

上述した予約支援システムにおいて、前記端末装置（２a）は、画像の選択によって日付情報の入力が可能な機能が付加されたカレンダー画像を取得可能な取得部（２１）をさらに備え、前記表示制御部（２３）は、前記ユーザによる操作が日付の入力に関する操作である場合には、前記カレンダー画像を表示させ、前記変換部（２４）は、前記入力部（２２）を介して前記カレンダー画像における日部分の画像の選択による日付情報の入力が行われた場合には、当該日付情報を日付についての文字情報に変換するようにしてもよい。

上述した予約支援システムにおいて、前記端末装置（２a）は、画像の選択によって場所情報の入力が可能な機能が付加された地図画像を取得可能な取得部（２１）をさらに備え、 前記表示制御部（２３）は、前記ユーザによる操作が場所の入力に関する操作である場合には、前記地図画像を表示させ、前記変換部（２４）は、前記入力部（２２）を介して前記地図画像の選択による場所情報の入力が行われた場合には、当該場所情報を場所についての文字情報に変換するようにしてもよい。

上述した予約支援システムにおいて、前記予約支援装置（１a）は、予め都道府県または都道府県より狭い範囲の地域に対応する推奨アクティビティ施設に関する推奨施設情報を記憶しており、前記端末装置（２a）において前記地図画像の選択による場所情報の入力が行われた場合、当該入力した場所情報に対応する都道府県または地域の推奨施設情報を前記予約支援装置（１a）から受信可能であるようにしてもよい。

上述した課題を解決するため、本発明に係る端末装置において、画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部（２１）と、前記ユーザによる操作に応じて、前記取得部（２１）で取得された前記画像を表示させる表示制御部（２３）と、前記ユーザによる操作に応じて情報を入力可能な入力部（２２）と、前記入力部（２２）を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置（１ａ）により解析可能な内容に変換する変換部（２４）とを備えることを特徴とする。

上述した端末装置（２ａ）において、前記端末装置（２ａ）は、前記端末装置（２ａ）での入力内容に応答する機能を有する予約支援装置（１ａ）と通信が可能であり、前記取得部（２１）は、画像の選択によって日付情報の入力が可能な機能が付加されたカレンダー画像を取得可能であり、前記表示制御部（２３）は、前記ユーザによる操作が日付の入力に関する操作である場合には、前記カレンダー画像を表示させ、前記変換部（２４）は、前記入力部（２２）を介して前記カレンダー画像における日部分の画像の選択による日付情報の入力が行われた場合には、当該日付情報を日付についての文字情報に変換するようにしてもよい。

上述した端末装置（２ａ）において、前記端末装置（２ａ）は、前記端末装置（２ａ）での入力内容に応答する機能を有する予約支援装置（１ａ）と通信が可能であり、前記取得部（２１）は、画像の選択によって場所情報の入力が可能な機能が付加された地図画像を取得可能であり、前記表示制御部（２３）は、前記ユーザによる操作が場所の入力に関する操作である場合には、前記地図画像を表示させ、前記変換部（２４）は、前記入力部（２２）を介して前記地図画像の選択による場所情報の入力が行われた場合には、当該場所情報を場所についての文字情報に変換するようにしてもよい。

上述した課題を解決するため、本発明に係る予約支援方法は、ユーザの端末装置（２ａ）を用いた予約を支援する予約支援方法であって、前記端末装置（２ａ）における入力の内容を解析し、前記解析の結果に応じて所定の内容を応答し、所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断し、前記予約に必要な情報が充足されていないと判断された場合に、前記必要な情報の入力を促す内容を応答し、前記予約に必要な情報が充足されたと判断された場合に、前記予約に必要な情報を登録し、画像の選択によって情報の入力が可能な機能が付加された画像を取得し、前記ユーザによる操作に応じて、前記取得した前記画像を表示し、前記ユーザによる操作に応じて情報を入力し、前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記解析が可能な内容に変換することを特徴とする。

上述した課題を解決するため、本発明に係る端末装置の制御方法は、ユーザの使用に係る端末装置（２ａ）と、当該端末装置（２ａ）と通信可能な予約支援装置（１ａ）とを備える予約支援システムにおける前記端末装置（２ａ）の制御方法であって、画像の選択によって情報の入力が可能な機能が付加された画像を取得し、前記ユーザによる操作に応じて、前記取得部で取得された前記画像を表示させ、前記ユーザによる操作に応じて情報を入力し、前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置（１４ａ）により解析可能な内容に変換することを特徴とする。

上述した課題を解決するため、本発明に係る端末装置のプログラムは、ユーザの使用に係る端末装置（２ａ）と、当該端末装置（２ａ）と通信可能な予約支援装置（１ａ）とを備える予約支援システムにおけるコンピュータを備える前記端末装置（２ａ）のプログラムであって、前記コンピュータを、画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部（２１）と、前記ユーザによる操作に応じて、前記取得部（２１）で取得された前記画像を表示させる表示制御部（２３）と、前記ユーザによる操作に応じて情報を入力可能な入力部（２２）と、前記入力部（２２）を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置（１ａ）により解析可能な内容に変換する変換部として機能させることを特徴とする。

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

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

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

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

図５に枠情報テーブル５ｂの一例を示す。枠情報テーブル５ｂには、図５に示すように、スタートＩＤごとに、日付、スタート時間、スタートコース、空き枠フラグ、及び１人予約枠フラグが関連付けられて記憶されている。ここで、本実施形態における「枠」とは、プレー日、プレーのスタート時間及びスタートコースにより特定される地位を指す。また、「空き枠」とはユーザによる予約がなされていない枠を指す。空き枠フラグの値が１の場合には、空き枠であることを示しており、空き枠フラグの値が０の場合には、予約が入っていることを示している。
スタートコースのフィールドに示される「ＯＵＴ」とは、ホール番号１のホールからラウンドが開始されることを示し、「ＩＮ」とは、ホール番号１０のホールからラウンドが開始されることを示している。但し、ゴルフ場によっては、東コース（１〜９番）、西コース（１〜９番）、南コース（１〜９番）等となっていることもあり、この場合には枠情報テーブル５ｂのスタートホールのフィールドには、「東」、「西」、「南」、若しくはこれらを意味する記号等が記憶されることになる。一般的に、ゴルフ場によって回る順番は決められており、例えば東コースからスタートすれば後半は西コース、西コースからスタートすれば後半は南コース、南コースからスタートすれば後半は東コース等と決まっているため、スタートコースが特定されれば足りる。

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

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

本実施形態における予約サーバ５は、各ゴルフ場のゴルフ場端末（図示せず）からアクセスが可能となっており、各ゴルフ場のゴルフ場ＩＤと関連付けてプラン情報テーブル５ａ、枠情報テーブル５ｂ、及び予約情報テーブル５ｃが記憶されている。
ユーザは、予約サーバ５に直接アクセスすることによってプラン情報や枠情報を参照し、予約を行うことが可能であるが、本実施形態では、後述するように、チャットサービスを介して予約を行うようになっている。詳しくは後述する。

なお、ゴルフ場端末（図示せず）は各ゴルフ場に設けられており、各ゴルフ場において、ゴルフ場の管理者等がゴルフ場端末を操作して設定されたプラン情報や枠情報などの内容が記憶されるようになっている。また、ゴルフ場端末は予約サーバ５と通信可能になっている。
ゴルフ場端末は、予約サーバ５に定期的にアクセスし、予約サーバ５に記憶された自分のゴルフ場の予約情報、枠情報を取得し、ゴルフ場端末に記憶された枠情報テーブル、及び予約情報テーブルを更新する。

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

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

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

予約支援サーバ１は、上述したように外部管理サーバ３によって提供されるメッセージ送受信サービスにおける専用アカウントとして登録されており、ユーザが端末装置２にインストールされたメッセージ送受信サービス用のアプリケーションソフトウェアを利用して前記専用アカウントと友達になり、当該アプリケーションソフトウェアを利用して前記専用アカウントにメッセージを送信した場合には、前記専用アカウントである予約支援サーバ１は、当該メッセージに応答することができる。
予約支援サーバ１は、解析部１０、応答部１１、判断部１２、応答制御部１３、登録部１４、候補提示部１５、記憶部１６、宛先検出部１７、予約検出部１８とを備えている。解析部１０、応答部１１、判断部１２、応答制御部１３、登録部１４、候補提示部１５は、予約支援サーバ１が予約支援サーバのプログラムを実行することにより発揮される機能ブロックである。
解析部１０は、端末装置２における入力の内容を解析する。応答部１１は、解析部１０における解析結果に応じて所定の内容を応答したり、宛先検出部１７によって一のユーザから送信されたメッセージの宛先として自身（予約支援サーバ１）以外の他のユーザが含まれていることが検出された場合、登録部１４において仮登録された情報を当該一のユーザ及び当該他のユーザに対して応答したりする。この場合、応答部１１は応答する内容（報告文）を作成する機能も有する。判断部１２は、一例として、ゴルフ場の予約に必要な情報が充足されたか否かを判断する。応答制御部１３は、判断部１２により予約に必要な情報が充足されていないと判断された場合に、必要な情報の入力を促す内容を応答部１１により応答させる。登録部１４は、判断部１２により予約に必要な情報が充足されたと判断された場合に、また、解析部１０により、仮登録されている情報が否定されたと判断された場合には、登録部１４は当該仮登録された情報を削除する。予約に必要な情報を予約支援サーバ１において仮登録し、または、予約サーバ５に登録する。候補提示部１５は、予約に必要な情報の項目について候補を提示する。
記憶部１６には、予約支援サーバ１を制御するプログラムが記憶され、さらに、上述した応答のための文例等が記憶されている。また、記憶部１６にはチャット履歴テーブル１６ａが記憶されている。このチャット履歴テーブル１６ａには、図２６Ａに示すように、外部管理サーバ３によって新規のチャット開始時に割り当てられたチャットＩＤ、メッセージの送信又は受信の日時、メッセージの差出人ユーザのユーザアカウント、メッセージの宛先ユーザのユーザアカウント、メッセージの内容、のフィールドが設けられている。なお、３人以上でチャットを行っている場合、宛先ＩＤのフィールドには差出人ユーザ以外の複数のユーザのユーザアカウントが記憶される。
また、記憶部１６には、チャットユーザ情報テーブル１６ｂが記憶されている。このチャットユーザ情報テーブル１６ｂは、図２６Ｂに示すように、メッセージ送受信サービスの専用アカウントの利用者であるユーザのユーザアカウント（ＵＩＤ）が記憶されるフィールドが、少なくとも設けられている。本実施形態では、ユーザアカウントの他、メッセージ送受信サービスのアプリケーションにおける名前として外部管理サーバ３に登録されている名前を記憶するフィールドも設けられている。
ここで、専用アカウントの利用者としてチャットユーザ情報テーブル１６ｂに登録される場合として、ユーザがメッセージ送受信サービスのアプリケーションにおいて専用アカウントを友達として登録した場合、及び、友達として登録はしていないが他のユーザからチャットに招待される等して専用アカウントを含むグループとしてチャットした履歴がある場合、がある。したがって、例えばユーザがメッセージ送受信サービスのアプリケーションにおいて専用アカウントを友達として登録した場合は、当該ユーザのユーザアカウントと、専用アカウントを友達として登録する旨の要求が外部管理サーバ３に送信される。外部管理サーバ３では、要求に基づいて専用アカウントと当該ユーザのユーザアカウントとを関連づけるとともに、予約支援サーバ１に対して、当該ユーザのユーザアカウント及び外部管理サーバ３に登録されている当該ユーザの名前を送信する。そして予約支援サーバ１は、外部管理サーバ３から受信したユーザアカウントを、チャットユーザ情報テーブル１６ｂに登録する。これにより専用アカウントの利用者であるユーザのユーザアカウントが、チャットユーザ情報テーブル１６ｂに記憶される。
宛先検出部１７は、ユーザから送信されたメッセージの宛先を検出するものであり、例えばユーザから送信されたメッセージの宛先として、自身（予約支援サーバ１）以外の他のユーザが含まれているか否かを検出する。予約検出部１８は、所定の場合に予約サーバ５の予約情報テーブル５ｃに記憶されている予約情報を検索し、特定の予約情報を検出する。例えば、一のユーザがゴルフを１人でプレーするための予約（すわなち１人予約）を行う場合、所定の範囲、例えば一のユーザの予約における場所と日付が同じ範囲、において、１人予約をしている他のユーザの予約情報を検索する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜４−１：予約の開始＞
まず、図１９のフローチャートを参照して、予約支援サーバ１の開始処理について説明する。メッセージ送受信アプリケーションにおいて、専用アカウントであるゴルフ予約Ａ１０をフレンド登録した直後においては、図１１に示すように、予約支援サーバ１側から、フレンド登録へのお礼Ｃ１９と日程入力要求メッセージＣ２０が送信される。具体的には、ユーザが自身の使用する端末装置２を操作して、ゴルフ予約Ａ１０をフレンド登録したとき、当該端末装置２から外部管理サーバ３を介して予約支援サーバ１に対して、当該ユーザがフレンド登録した旨と、そのユーザのユーザＩＤが送信される。これを受信した予約支援サーバ１は、フレンド登録時に登録したユーザに対して返答するメッセージを、受信したユーザＩＤを宛先として外部管理サーバ３に対してお礼Ｃ１９と日程入力要求メッセージＣ２０を送信する。図１１の例では、メッセージ表示領域Ｃ２に、「フレンド登録ありがとう！どんどん活用してくださいね。」というメッセージと、「ゴルフに行きたい日があったら数字４ケタで教えてくださいね。」というメッセージが表示される。このメッセージは、記憶部１６の文例テーブルに予め記憶されており、状況に応じて適切な文例を文例テーブルから読み取って、応答部１１が送信するようになっている。

したがって、ゴルフ場の予約を希望するユーザは、この日程入力要求メッセージＣ２０に対して、図１２に示すように、ゴルフ場を予約する日を送信することができる。図１２の例では、ユーザは「０８２５」というメッセージＣ２１を送信している。このように数字が送信された場合には、図１９のラベルＬＢ１〜ＬＢ１２に続く各ステップに示すような日付判断処理等が行われることになる。そして、以下、図１２に示すように、対話形式でゴルフ場の予約が行われることになる。日付判断処理等についての詳細については、後述する。

しかし、一旦、専用アカウントであるゴルフ予約Ａ１０をフレンド登録し、図１２に示すように専用アカウントであるゴルフ予約Ａ１０とチャット上のやり取りを行った後においては、ユーザからの何らかのメッセージの送信がない限り、予約支援サーバ１側からメッセージを送信することはない。また、図１１に示すように、予約支援サーバ１側から日程入力要求メッセージＣ２０を送信した場合であっても、その後にユーザからの何らかのメッセージが送信されなければ、予約支援サーバ１側から何らかのメッセージを送信することはない。

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

しかし、上述したいずれでもない場合、例えば、図１３に示すように、「予約したい！」というメッセージＣ３０が送信された場合、あるいは、「予約」と送信された場合、もしくは、「ｔｔ」等の意味のないメッセージが送信された場合には、本実施形態では、予約支援サーバ１のＣＰＵ３０は、メッセージの内容を解析し（図１９；Ｓ９０）、解析の結果、予約要求があったと判断する。なお、後述のように日程や場所等の仮登録がなされた後で、「ｔｔ」等の意味のないメッセージが送信された場合は、「認識できません」等の応答を行ってもよい。

そして、予約支援サーバ１のＣＰＵ３０は、予約要求があったと判断した場合には、ラベルＬＢ１に続いて記載された処理、つまり、日程入力の要求メッセージを送信する処理を行う（Ｓ１０１）。図１３に示す例では、ＣＰＵ３０は、「ゴルフの予約ですね。行きたい日を数字４ケタで教えてください。」というメッセージＣ３１を送信する。このメッセージも、記憶部１６の文例テーブルに予め記憶されており、状況に応じて適切な文例を文例テーブルから読み取って、送信するようになっている。以下、予約支援サーバ１側からメッセージを送信する場合には、状況に応じて適切な文例を文例テーブルから読み取って送信する。

＜４−２：日付判断処理＞
受信したメッセージの内容が、図１３に示すように数字４ケタのメッセージＣ３０であった場合には、予約支援サーバ１のＣＰＵ３０は、メッセージの内容を解析し（図１９；Ｓ９０）、解析の結果、ゴルフ場を予約する日付が送信されたと判断する。そして、ＣＰＵ３０は、日付が送信されたと判断した場合には、ラベルＬＢ２に続いて記載された処理を行う。まず、ＣＰＵ３０は、「８月２５日ですね。」等の確認のメッセージＣ３４を送信して、受信したメッセージの内容である日付を仮登録する（図１９；Ｓ２０１）。なお、本実施形態において仮登録とは、受信したメッセージの内容を一時的に予約支援サーバ１の記憶部１６に記憶させておくことをいう。また、本実施形態においては、日付などの仮登録する情報を、チャットＩＤと関連付けて仮登録を行う。
次に、予約支援サーバ１のＣＰＵ３０は、ゴルフ場の仮登録が行われたかどうかを判断し（図１９；Ｓ２０２）、まだゴルフ場の仮登録が行われていない場合には（図１９；Ｓ２０２：ＮＯ）、ユーザの住所が入力済みであるかどうかを判断する（図１９；Ｓ２０４）。住所が入力済みではない場合には（図１９；Ｓ２０４：ＮＯ）、ＣＰＵ３０は、住所の入力を要求するメッセージを送信する（図１９；Ｓ２０５）。図１３に示す例では、ＣＰＵ３０は、「８月２５日ですね。」という確認のメッセージＣ３４を送信した後に、「おすすめのゴルフ場を探してみます。位置情報をおしえてくださいね。」というメッセージＣ３５を送信する。

一方、ゴルフ場の仮登録が行われている場合には（図１９；Ｓ２０２：ＹＥＳ）、つまり、先にゴルフ場の仮登録が行われた後に、日付の仮登録（図１９；Ｓ２０１）が行われた場合には、ＣＰＵ３０は、枠情報テーブル５ｂを参照して、仮登録したゴルフ場及び日付に該当する空き枠情報を抽出し、承認を要求するメッセージを送信する（図１９；Ｓ２０３）。

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

また、ユーザの住所が入力済みの場合には（図１９；Ｓ２０４：ＹＥＳ）、つまり、先に住所の入力が行われた後に、日付の仮登録（図１９；Ｓ２０１）が行われた場合には、図２０に示すように、ＣＰＵ３０は、入力された住所に基づいて、お勧めのゴルフ場の検索を行う（図２０；Ｓ８０２）。検索の後、ＣＰＵ３０は、お勧めのゴルフ場を表示して、ユーザの承認を要求するメッセージを送信する（図２０；Ｓ８０３）。
例えば、図１３に示す例では、ＣＰＵ３０は、「では赤坂ゴルフ倶楽部はどうでしょう？車で１時間４０分くらいです。」というメッセージＣ３７を送信する。このメッセージは、ゴルフ場を表示して、ユーザの承認を要求するメッセージである。

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

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

また、図１４に示すように、確認メッセージＣ５４の送信の直後に、仮登録した日付を取り消すメッセージＣ５５が送信された場合には、予約支援サーバ１のＣＰＵ３０は、日付を否定する内容を受信したと判断し、図２０に示すラベルＬＢ９に続いて記載されたステップＳ１００１以下の処理が行われる。ステップＳ１００１では、仮登録済情報を削除して、確認のメッセージを送信する。図１４の例では、「０８２５ムリ」という日付を否定するメッセージＣ５５を受信した後に、８月２５日の日付の仮登録済情報を削除して、「８月２５日はＮＧになったんですね。わかりました。」という確認のメッセージＣ５６を表示させる。次に、他の候補があるかどうかを判断し（図２０；Ｓ１００２）、この場合には他に候補はないので（図２０；Ｓ１００２：ＮＯ）、新たな日程の入力を要求するメッセージを表示させる（Ｓ１００４）。しかし、この例では、８月２５日以外の日付が仮登録されているので、新たな日程の入力を要求するメッセージは表示させない。他の候補がある場合には（図２０；Ｓ１００２：ＹＥＳ）、ＣＰＵ３０は、当該他の候補を表示させ、承認を要求する（図２０；Ｓ１００３）。但し、他の候補があると判断した直後に当該他の候補を表示させるのではなく、図１４に示すように、ユーザからのメッセージの入力を待ち、当該入力に対する応答をした後に他の候補を表示させるようにしてもよい。

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

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

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

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

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

また、日程の入力を要求するメッセージを送信したにも拘わらず、例えば、「東京都」等のように日程とは無関係の送信が行われることも考えられる。この場合には、エラーとして判断するようにしてもよいが、本実施形態では、受信したメッセージの内容を解析し、例えば都道府県についての内容であると判断した場合には、ゴルフ場の検索処理を行うようになっている。本実施形態では、このように、どのような問い掛けを行ったかどうかに拘わらず、ユーザが送信したメッセージの内容を解析して適切な処理を行う。すなわち本実施形態においては、受信したメッセージの内容が、応答部１１からの問いかけに対する回答とは異なるが、解析部１０による解析の結果、他の問いかけに対する回答に相当する場合は、当該他の問いかけに対する回答であると解析することとしている。従って、日程からでも、また、場所からでも、予約に必要な情報を決定していくことができる。
具体的には、例えば日程の問いかけに対する回答かどうかの判断処理の一例を、図２４に示す。
１）予約支援サーバ１のＣＰＵ３０は、メッセージの内容が８桁の数字の文字列であるかどうかを判断する（Ｓ１５００）。判断の結果が否定的な場合には（Ｓ１５００：ＮＯ）、ＣＰＵ３０は、Ｓ１５０３の判断に移行する。Ｓ１５００の判断の結果が肯定的な場合には（Ｓ１５００：ＹＥＳ）、ＣＰＵ３０は、上位４桁がその年又は翌年の西暦に合致するかどうかを判断する（Ｓ１５０１）。判断の結果が否定的である場合には（Ｓ１５００：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１２）。
しかし、Ｓ１５０１の判断の結果が肯定的である場合には（Ｓ１５０１：ＹＥＳ）、ＣＰＵ３０は、下位４桁を抽出し（Ｓ１５０２）、そのうちの上位２桁が０１〜１２であるかどうかを判断する（Ｓ１５０４）。上位２桁が０１〜１２ではない場合には（Ｓ１５０４：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１２）。上位２桁が０１〜１２である場合には（Ｓ１５０４：ＹＥＳ）、ＣＰＵ３０は、下位２桁が、上位２桁の数字に応じて、０１以上であって、２８、２９、３０、３１のいずれか、又は以下であるかどうかを判断する（Ｓ１５０５）。判断の結果が否定的な場合には（Ｓ１５０５：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１２）。Ｓ１５０５の判断の結果が肯定的な場合には（Ｓ１５０５：ＹＥＳ）、ＣＰＵ３０は、メッセージの内容が日程の問いかけに対する回答であると判断する（Ｓ１５１０）。

２）予約支援サーバ１のＣＰＵ３０は、メッセージの内容が４桁の数字の文字列であるかどうかを判断する（Ｓ１５０３）。判断の結果が否定的な場合には（Ｓ１５０３：ＮＯ）、ＣＰＵ３０は、Ｓ１５０６の判断に移行する。Ｓ１５０３の判断の結果が肯定的な場合には（Ｓ１５０３：ＹＥＳ）、ＣＰＵ３０は、上位２桁が０１〜１２であるかどうかを判断する（Ｓ１５０４）。上位２桁が０１〜１２ではない場合には（Ｓ１５０４：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１２）。上位２桁が０１〜１２である場合には（Ｓ１５０４：ＹＥＳ）、ＣＰＵ３０は、下位２桁が、上位２桁の数字に応じて、０１以上であって、２８、２９、３０、３１のいずれか、又は以下であるかどうかを判断する（Ｓ１５０５）。判断の結果が否定的な場合には（Ｓ１５０５：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１２）。Ｓ１５０５の判断の結果が肯定的な場合には（Ｓ１５０５：ＹＥＳ）、メッセージの内容が日程の問いかけに対する回答であると判断する（Ｓ１５１０）。

３）予約支援サーバ１のＣＰＵ３０は、メッセージの内容が、数字又は漢数字と「月」が組み合わされた文字列であって、数字又は漢数字が１〜１２の範囲にあるかどうかを判断する（Ｓ１５０６）。判断の結果が否定的な場合には（Ｓ１５０６：ＮＯ）、ＣＰＵ３０は、Ｓ１５０７の判断に移行する。Ｓ１５０６の判断の結果が肯定的な場合には（Ｓ１５０６：ＹＥＳ）、ＣＰＵ３０は、メッセージの内容が日程の問いかけに対する回答であると判断する（Ｓ１５１０）。

４）予約支援サーバ１のＣＰＵ３０は、メッセージの内容が、数字又は漢数字と「月」及び「日」が組み合わされた文字列かどうかを判断する（Ｓ１５０７）。判断の結果が否定的な場合には（Ｓ１５０７：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１１）。Ｓ１５０７の判断の結果が肯定的な場合には（Ｓ１５０７：ＹＥＳ）、ＣＰＵ３０は、「月」の前の数字又は漢数字が１〜１２の範囲かどうかを判断する（Ｓ１５０８）。判断の結果が否定的な場合には（Ｓ１５０８：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１１）。Ｓ１５０８の判断の結果が肯定的な場合には（Ｓ１５０８：ＹＥＳ）、ＣＰＵ３０は、「日」の前の数字又は漢数字が、「月」の前の数字又は漢数字に応じて、１以上であって、２８、２９、３０、３１のいずれか、又は以下であるかどうかを判断する（Ｓ１５０９）。判断の結果が否定的な場合には（Ｓ１５０９：ＮＯ）、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断する（Ｓ１５１１）。Ｓ１５０９の判断の結果が肯定的な場合には（Ｓ１５０９：ＹＥＳ）、ＣＰＵ３０は、メッセージの内容が日程の問いかけに対する回答であると判断する（Ｓ１５１０）。

なお、ＣＰＵ３０は、メッセージの内容が日程に関するものではないと判断した場合には、ゴルフ場名や地名などの他の内容であるかどうかを判断する。ＣＰＵ３０は、いずれの内容にも該当しないと判断した場合には、不適切な入力であるので、「認識できませんでした。もう一度入力してください。」等とユーザに対して応答するようにしてもよい。
また、ゴルフ場名や地域名については、本実施形態では、ゴルフ場名、都道府県名、市区町村といった都市名、の漢字、平仮名、片仮名をそれぞれ記憶しておく。そしてユーザから受信したメッセージの内容がこれらに該当するか否かを判断することにより、後述のように、メッセージの内容が、ゴルフ場名、都道府県名または都市名であると判断することとなる。

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

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

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

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

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

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

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

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

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

本実施形態においては、外部管理サーバ３の記憶部には、チャット処理についての情報が記憶されるチャット情報テーブル３ｂが備えられている。チャット情報テーブル３ｂは、図２５に示すように、チャットＩＤ、受付日時、差出人ＩＤ、宛先ＩＤが記憶される。ユーザが、図９に示すチャット画面Ｐ２において、フレンド表示領域Ｂ２に表示されるいずれかのユーザを選択し、チャットアイコンＡ７を押下すると、端末装置２のＣＰＵ４０は、外部管理サーバ３に対して、チャット処理の開始要求を送信する。チャット処理の開始要求を受信した外部管理サーバ３のＣＰＵは、当該チャット処理を一意に識別するチャットＩＤを割り当て、当該チャットＩＤを、チャット情報テーブル３ｂのチャットＩＤのフィールドに記憶させる。

また、外部管理サーバ３のＣＰＵは、前記チャット処理の開始要求を受け付けた日時を、チャット情報テーブル３ｂの受付日時のフィールドに記憶させる。さらに、外部管理サーバ３のＣＰＵは、前記チャット処理の開始要求を送信した端末装置２のユーザである第１のユーザのユーザアカウントを、チャット情報テーブル３ｂの差出人ＩＤのフィールドに記憶させる。また、外部管理サーバ３のＣＰＵは、前記チャット処理の相手として選択された第２のユーザのユーザアカウントを、チャット情報テーブル３ｂの宛先ＩＤのフィールドに記憶させる。宛先ＩＤのフィールドは複数用意されており、複数のユーザのユーザアカウントを記憶させることができる。該当するユーザが存在しない場合には、宛先ＩＤのフィールドにはnullが記憶される。

外部管理サーバ３のＣＰＵは、以上のようにチャットＩＤ等をチャット情報テーブル３ｂに記憶させた後、図１０に示すメッセージ表示画面Ｐ３を、前記チャット処理の開始要求を送信した前記端末装置２に表示させる。当該端末装置２において、第１のユーザがメッセージを入力すると、外部管理サーバ３のＣＰＵは、当該メッセージを、第２のユーザ宛に送信する。同様に、第２のユーザがメッセージを入力すると、外部管理サーバ３のＣＰＵは、当該メッセージを、第１のユーザ宛に送信する。このようにしてチャット処理が行われることになる。

以上のような処理は、ユーザが誰かとチャットを行っている状態で、新たな友達を招待した際にも同様に行われる。つまり、第１のユーザが第２のユーザとチャットを行うと、当該チャットに対してチャットＩＤが割り当てられるが、この状態で、新たな第３のユーザを招待した際には、外部管理サーバ３のＣＰＵは、第１のユーザ、第２のユーザ、及び第３のユーザによる新たなチャット処理の開始要求があったと判断し、この新たなチャットに対して新たなチャットＩＤを割り当てる。

例えば、第１のユーザが図１６に示す機能ボタンＣ１１を押下すると、「友達を招待する」というボタンが表示され（図示省略）、このボタンを押すと招待する友達を選択する画面が表示される（図示省略）。この画面において、第１のユーザが、第２のユーザとして専用アカウントであるゴルフ予約Ａ１０と、第３のユーザである友達のユーザを招待した際には、外部管理サーバ３のＣＰＵは、新たなチャット処理の開始要求があったと判断し、この新たなチャットに対して新たなチャットＩＤを割り当てる。そして、外部管理サーバ３のＣＰＵは、チャット処理の開始要求を受け付けた日時を、チャット情報テーブル３ｂの受付日時のフィールドに記憶させ、第１のユーザのユーザアカウントを差出人ＩＤのフィールドに、ゴルフ予約Ａ１０のユーザアカウントと、第３のユーザである友達のユーザアカウントを、宛先ＩＤのフィールドに記憶させる。

一方、第１のユーザの端末装置２のＣＰＵ４０は、図１６に示すように、新たなチャットルームが設定されるとともに、「ゴルフ予約さん、美希さんが参加しました。」というメッセージＣ７０を端末装置２に表示させる。
但し、この状態では、招待された友達と専用アカウントであるゴルフ予約Ａ１０は、招待されたことを検知することはできない。
しかし、図１６のメッセージＣ７１のように、招待した第１のユーザが何等かのメッセージを送信した場合には、招待した第１のユーザの端末装置２に予め記憶されている、第１のユーザのユーザアカウント、招待された友達である第２のユーザのユーザアカウント、及び、ゴルフ予約Ａ１０のユーザアカウントと共に、前記メッセージが、予約支援サーバ１に送信される。予約支援サーバ１のＣＰＵ３０は、これらのユーザアカウントを検知することにより、第１のユーザがゴルフ予約Ａ１０と第２のユーザ宛にメッセージを発信したこと、つまり、友達を招待した場合であると判断することができる（図２０：ＬＢ８）。

次に、予約支援サーバ１のＣＰＵ３０は、仮登録情報の抽出処理を行う（図２０：Ｓ９０１）。具体的には、予約支援サーバ１のＣＰＵ３０は、まず、図２６Ａに示すチャット履歴テーブル１６ａから、差出人である第１のユーザのユーザアカウントが、差出人ＩＤまたは宛先ＩＤとして記憶されているレコードを抽出する。当該レコードが抽出できなかった場合には、予約支援サーバ１のＣＰＵ３０は、今回の新たなチャットに表示すべき仮登録情報はないと判断する。
しかし、当該レコードが抽出された場合には、予約支援サーバ１のＣＰＵ３０は、抽出されたレコードの中から、受付日時が直近の所定時間以内、例えば１週間以内のレコードを抽出する。当該レコードが抽出できなかった場合には、予約支援サーバ１のＣＰＵ３０は、今回の新たなチャットに表示すべき仮登録情報はないと判断する。しかし、当該レコードが抽出された場合には、予約支援サーバ１のＣＰＵ３０は、抽出されたレコードからチャットＩＤを読み出す。

予約支援サーバ１のＣＰＵ３０は、予約支援サーバ１のＣＰＵ３０は、受信した差出人ＩＤと宛先ＩＤの中に、今回の新たなチャットの参加メンバー以外のメンバーのユーザアカウントが含まれていないかどうかを確認する。例えば、今回の新たなチャットの参加メンバーは、第１のユーザ、第２のユーザ、及びゴルフ予約Ａ１０なので、受信した差出人ＩＤと宛先ＩＤに含まれるユーザアカウントが、第１のユーザとゴルフ予約Ａ１０のユーザアカウントであれば、直近の所定時間以内に行われた第１のユーザとゴルフ予約Ａ１０とのチャットであることが判る。したがってこの場合は、予約支援サーバ１のＣＰＵ３０は、当該チャットＩＤについては除外しない。しかし、受信した差出人ＩＤと宛先ＩＤに含まれるユーザアカウントが、第１のユーザと、今回の新たなチャットの参加メンバーではない第３のユーザのユーザアカウントである場合には、当該チャットＩＤに係るチャットは、今回の新たなチャットとは無関係のチャットであると判断し、予約支援サーバ１のＣＰＵ３０は、当該チャットＩＤについては除外する。

以上のような処理により、除外されずに残ったチャットＩＤが存在している場合には、予約支援サーバ１のＣＰＵ３０は、当該チャットＩＤに係るチャットのメッセージを検索することにより、予約処理が完了していないチャットがあるかどうかを判断する。具体的には、予約支援サーバ１のＣＰＵ３０は、チャット履歴テーブル１６ａから、当該チャットＩＤのメッセージを抽出し、予約処理が完了していないかどうかを解析する。例えば、抽出したメッセージ中に、「予約しました。」等のメッセージが残されていれば、予約支援サーバ１のＣＰＵ３０は、予約処理が完了していると判断できる。しかし、抽出したメッセージの中に、このようなメッセージがない場合には、予約支援サーバ１のＣＰＵ３０は、予約処理が完了していないと判断できる。予約支援サーバ１のＣＰＵ３０は、予約処理が完了していないと判断した場合には、当該チャットＩＤに関連付けられた仮登録情報を抽出する（図２０：Ｓ９０１）。本実施形態では、仮登録情報は、チャットＩＤ及びユーザアカウントと関連付けられて記憶されているので、チャットＩＤが判れば仮登録情報を読み出すことができる。
なお、例えば上記のような処理によっても複数のチャットＩＤが予約処理が完了していないとして残る場合がある。この場合、より直近のチャット履歴が残っているチャットＩＤに関連付けられた仮登録情報を抽出することとしてもよいし、複数のチャットＩＤが残った場合はいずれも採用せず、新規の予約であると判断して仮登録情報の抽出は行わないこととしてもよいし、その他の方法を採用してもよい。

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

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

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

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

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

また、他に候補がない場合には（図２０；Ｓ１００１：ＮＯ）、ＣＰＵ３０は、仮登録情報を削除する（図２０；Ｓ１００３）。例えば、日程の情報の入力が要求されている場合に、「０９０１」というメッセージが送信されると、日程として９月１日が仮登録されるが、その後に、「０９０１ムリ」のようなメッセージが送信された場合には、９月１日という日程の仮登録は削除されることになる。そして、ＣＰＵ３０は、新たに日程の入力を要求するメッセージを送信する（図２０；Ｓ１００４）。

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

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

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

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

そして、日程、ゴルフ場、枠の全ての情報について仮登録が行われている場合には、（図２１；Ｓ１２０６：ＹＥＳ）、ＣＰＵ３０は、予約サーバ５に対する予約情報の本登録処理を行い（図２１；Ｓ１２０８）、予約が完了した旨を表示させる（図２１；Ｓ１２０９）。但し、友達が招待されている状態においては、特に枠情報については、招待したユーザと、招待された友達の全員の承認が必要であると考えられる。招待された友達が複数である場合には、招待したユーザと、招待された複数の友達の全員の承認が必要であると考えられる。そこで、本実施形態では、予約サーバ５に対する予約情報の本登録処理を行う前に、ＣＰＵ３０は、枠情報について、否定的なメッセージが送信されていないかどうか、あるいは、招待したユーザと、招待された友達の全員の肯定的なメッセージが送信されているかどうかを判断する。枠情報について、否定的なメッセージが送信されておらず、あるいは、招待したユーザと、招待された友達の全員の肯定的なメッセージが送信されている場合には、ＣＰＵ３０は、予約サーバ５に対する予約情報の本登録処理を行い（図２１；Ｓ１２０８）、予約が完了した旨を表示させる（図２１；Ｓ１２０９）。
なお、本登録処理が行われる際には、予約サーバ５において予約登録を行う場合の予約者ＩＤと、外部管理サーバ３によって提供されるメッセージ送受信アプリケーションのユーザアカウントとの関連付けが、予約支援サーバ１のＣＰＵ３０によって行われる。具体的には、予約支援サーバ１のＣＰＵ３０は、本登録処理を行う際に、ユーザに対して、予約サーバ５へのログイン情報、具体的には予約者ＩＤを入力するように要求する。この時に入力される予約者ＩＤと、ユーザアカウントとを関連付けて記憶部１６に記憶させる。したがって、ゴルフ予約Ａ１０とユーザとの対話時に、予約支援サーバ１のＣＰＵ３０は、ユーザアカウントと関連付けられた予約者ＩＤを利用することにより、当該ユーザの過去の予約履歴等を検索し、検索した過去の予約履歴等をゴルフ予約Ａ１０に投稿して表示させることができる。

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

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

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

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

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

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

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

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

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

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

予約サーバ５への本登録処理が完了した後は、図２３に示す１人予約処理に移行するが（図２１；接続端子Ｄ）、この１人予約処理については後述する。

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

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

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

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

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

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

＜４−８：１人予約処理＞
ユーザが図１７に示すように「１人で行く」というメッセージＣ８０、あるいは、「１人予約」等のようなメッセージを送信した場合には、予約支援サーバ１のＣＰＵ３０は、１人予約が行われると判断し、ラベルＬＢ１２に続いて記載された処理を行う。本実施形態では、１人予約を行う旨の明示の要求がない場合には、原則として利用人数は複数という前提で、ゴルフ場や空き枠情報の抽出が行われる。しかし、１人予約が行われると判断した場合には、１人予約の枠を用意しているゴルフ場、あるいは、１人予約用に分割できるプランを検索する必要があるので、ＣＰＵ３０は、１人予約フラグをオン状態にする（図２１；Ｓ１３０１）。

また、ゴルフ場の仮登録や、日程の仮登録を行った後等を行った後に１人予約である旨の明示が行われることも考えられるため、上記のように１人予約フラグがオン状態にされると（図２２；Ｓ１３０１）、ＣＰＵ３０は、日程の仮登録が行われているかどうかを判断し（図２２；Ｓ１３０２）、日程の仮登録が行われていない場合は（図２２；Ｓ１３０２：ＮＯ）、ＣＰＵ３０は、日程の入力を要求する（図２２；Ｓ１３０３）。一方、日程の仮登録が行われている場合は（図２２；Ｓ１３０２：ＹＥＳ）、ＣＰＵ３０は、ゴルフ場の仮登録が行われているかどうかを判断する（図２２；Ｓ１３０４）。ゴルフ場の仮登録が行われている場合は、ＣＰＵ３０は、既に枠情報の仮登録が行われているかどうかを判断する（図２２；Ｓ１３０５）。枠情報の仮登録が行われている場合には（図２２；Ｓ１３０５：ＹＥＳ）、ＣＰＵ３０は、その枠が１人予約対応かどうかを判断する（図２２；Ｓ１３０６）。具体的には、枠の仮登録情報には、その枠のスタートＩＤが記憶されているので、ＣＰＵ３０は、記憶されたスタートＩＤに基づいて図５の枠情報テーブル５ｂを参照し、記憶されたスタートＩＤの属する枠における１人予約フラグが１か０かを判断する。１人予約フラグが０の場合には、ＣＰＵ３０は、その枠は１人予約に対応していない枠であると判断し（図２２；Ｓ１３０６：ＮＯ）、枠が１人予約に対応していない旨のメッセージを表示して、仮登録情報を削除するとともに、次のステップＳ１３０７へ進む。

ＣＰＵ３０は、その枠は１人予約に対応している枠であると判断した場合には（図２２；Ｓ１３０６：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、予約サーバ５に対して本登録処理を行い（図２２；Ｓ１２０８）、予約を完了した旨のメッセージＣ９０を送信する（図２２；Ｓ１２０９）。

ＣＰＵ３０は、枠が１人予約に対応していないと判断した場合（図２２；Ｓ１３０６：ＮＯ）、または枠情報の仮登録が行われていないと判断した場合には（図２２；Ｓ１３０５：ＮＯ）、当該仮登録されたゴルフ場において、仮登録された日程で１人予約用の空き枠が存在するかどうかを判断する（図２２；Ｓ１３０７）。具体的には、ＣＰＵ３０は、枠情報テーブル５ｂを参照し、仮登録された日程における枠情報をチェックし、１人予約枠フラグが「１」であるものを検索する。そして該当する空き枠が発見された場合（図２２；Ｓ１３０７：ＹＥＳ）、ＣＰＵ３０は、当該発見した空き枠の情報を提示し、ユーザの承認を要求する（図２２；Ｓ１３０８）。

一方、空き枠が発見されなかった場合（図２２；Ｓ１３０７：ＮＯ）、ＣＰＵ３０は、住所情報が記憶されているかどうかを判断する（図２２；Ｓ１３０９）。ＣＰＵ３０は、住所情報（位置情報）が記憶されていないと判断した場合（図２２；Ｓ１３０９：ＮＯ）、ゴルフ場を再検索するため、住所又はゴルフ場名の入力を要求する（図２２；Ｓ１３１０）。ＣＰＵ３０は、住所情報が記憶されていると判断した場合（図２２；Ｓ１３０９：ＹＥＳ）、当該住所情報に基づいてゴルフ場の検索を行う（図２２；Ｓ１３１１）。この検索においては、ＣＰＵ３０は、各ゴルフ場の枠情報に１人予約用の空き枠が存在するかどうかも判断する。この判断方法は上述の通りである。
そしてＣＰＵ３０は、１人予約用の空き枠が存在するゴルフ場を提示し、ユーザの承認を要求する（図２２；Ｓ１３１２）。

予約サーバ５に対して本登録処理が終了した後は、予約支援サーバ１のＣＰＵ３０は、図２３に示すように、１人予約フラグがオン状態か否かを判断する（図２３；Ｓ１４００）。１人予約フラグがオン状態ではない場合、つまり、通常の予約の場合には（図２３；Ｓ１４００：ＮＯ）、ＣＰＵ３０は、その他の処理は行わず、予約処理を完了させる。

しかし、１人予約フラグがオン状態の場合、つまり、図１７のように１人予約を宣言した場合には（図２３；Ｓ１４００：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、１人予約フラグをオフ状態とし（図２３；Ｓ１４０１）、予約の本登録を行ったゴルフ場において、予約を行った日と同日に、他に１人予約者がいないかどうかを判断する（図２３；Ｓ１４０２）。この判断は、予約サーバ５の予約情報テーブル５ｃにおいて、１人予約枠のプランＩＤを含むレコードのうち、予約した日と同日のレコードを抽出することによって行えばよい。

予約の本登録を行ったゴルフ場において、予約を行った日と同日に、他に１人予約者がいない場合には（図２３；Ｓ１４０２：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、「メッセージを残しますか？」のような問合せのメッセージＣ９１を送信する。
所定時間、例えば５分程度待っても何もメッセージが送信されない場合、あるいは、「メッセージはないです。」等の否定的な内容が送信された場合には、ＣＰＵ３０は、１人予約をする人に対してメッセージを残さないと判断し（図２３；Ｓ１４０３：ＮＯ）、その他の処理を行わずに処理を終了する。
一方、この問合せに対して、「はい。」等の肯定的なメッセージＣ９２が送信された場合には、予約支援サーバ１のＣＰＵ３０は、ユーザがメッセージを残すと判断し（図２３；Ｓ１４０３：ＹＥＳ）、「では、メッセージをお願いします。」等のメッセージＣ９３を送信して応答する。

そして、図１７に示すように、１人予約をする人に対するメッセージＣ９４が送信された場合には、そのメッセージを受信し（図２３；Ｓ１４０４）、予約支援サーバ１のＣＰＵ３０は、当該予約情報の予約ＩＤと関連付けて、１人予約をする人に対するメッセージを記憶部１６に記憶する（図２３；Ｓ１４０５）。なお、メッセージを受信した場合には、予約支援サーバ１のＣＰＵ３０は、「メッセージを受け付けました。では当日お楽しみください。」等の応答を行ってもよい。

この後、別のユーザが、図１８に示すように、同じゴルフ場で同日に１人予約を行ったとする。図１８においては、１人予約を行うことの宣言、日程の入力、住所の入力等の過程は省略している。
この場合には、予約支援サーバ１のＣＰＵ３０は、予約完了のメッセージＣ１０２を送信した後、１人予約フラグがオン状態か否かを判断する（図２３；Ｓ１４００）。１人予約フラグがオン状態の場合、つまり、図１７のように１人予約を宣言した場合には（図２３；Ｓ１４００：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、１人予約フラグをオフ状態とし（図２３；Ｓ１４０１）、予約の本登録を行ったゴルフ場において、予約を行った日と同日に、他に１人予約者がいないかどうかを判断する（図２３；Ｓ１４０２）。図１７に示すように、同じゴルフ場に同日に１人予約者がいる場合には、予約サーバ５の予約情報テーブル５ｃにおいて、１人予約枠のプランＩＤを含むレコードのうち、予約した日と同日のレコードが抽出されるので、ＣＰＵ３０は、予約の本登録を行ったゴルフ場において、予約を行った日と同日に、他に１人予約者がいると判断し（図２３；Ｓ１４０２：ＹＥＳ）、その予約情報を見るかどうかを問い合わせるメッセージを送信する。ここで、その１人予約者がメッセージを残している場合には、ＣＰＵ３０は、図１８のように、そのメッセージを見るかどうかを問い合わせるメッセージＣ１０３を送信する。その１人予約者がメッセージを残していない場合は、ＣＰＵ３０は、例えば「既に１人分の予約が入っています。情報を見ますか？」等のメッセージを送信する。なお、該当する１人予約者が複数いる場合には、ＣＰＵ３０は、スタート時間が最も近い１人予約者を抽出するようにすればよい。また、ＣＰＵ３０は、ユーザの住所と最も近い住所の１人予約者を抽出するようにしてもよい。さらに、ＣＰＵ３０は、複数の１人予約者をリスト状にして表示させてもよい。

そして、この問合せに対して、「見ない」等の否定的なメッセージがユーザから送信された場合、あるいは、所定時間、例えば５分間、何も送信されなかった場合には、予約支援サーバ１のＣＰＵ３０は、そのメッセージを表示させないと判断し（図２３；Ｓ１４０６：ＮＯ）、その他の処理を行わずに予約処理を完了する。この場合にも、「わかりました。では当日お楽しみください。」等の応答を行ってもよい。

しかし、図１８に示すように、「見る」等の肯定的なメッセージＣ１０４がユーザから送信された場合には、予約支援サーバ１のＣＰＵ３０は、そのメッセージを表示させると判断し（図２３；Ｓ１４０６：ＹＥＳ）、図１８に示すように、記憶部１６に記憶させておいたメッセージと、一緒にゴルフに行くかどうかを尋ねるメッセージとを含むメッセージＣ１０５を表示させる。そして、予約支援サーバ１のＣＰＵ３０は、メッセージを見たユーザが、メッセージを残したユーザと一緒にゴルフに行くことを了承するかどうか、すなわちメッセージを残したユーザが登録されている予約枠に参加するか否か、を判断する（図２３；Ｓ１４０７）。

ここで、「いいえ。」等の否定的なメッセージがユーザから送信された場合には、予約支援サーバ１のＣＰＵ３０は、メッセージを残したユーザと一緒にゴルフに行くことが了承されなかったと判断し（図２３；Ｓ１４０７：ＮＯ）、その他の処理を行わずに予約処理を完了する。この場合にも、「わかりました。では当日お楽しみください。」等の応答を行ってもよい。

しかし、「はい。」等の肯定的なメッセージＣ１０６がユーザから送信された場合には、予約支援サーバ１のＣＰＵ３０は、メッセージを残したユーザと一緒にゴルフに行くことが了承されたと判断し（図２３；Ｓ１４０７：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、先に予約された１人予約者と、上述のように当該１人予約者と一緒にゴルフに行くことを了承した１人予約者との予約情報を関連付ける、予約情報の修正処理を行う（図２３；Ｓ１４０８）。具体的には、ＣＰＵ３０は、当該一緒にゴルフに行くことを了承した１人予約者の予約情報のスタートＩＤを、先に予約された１人予約者が含まれる予約情報のスタートＩＤと同一のＩＤに変更する処理を行う。

次に、「「メッセージを残しますか？」のような問合せのメッセージを送信する。この問合せに対して、「はい。」等の肯定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、ユーザがメッセージを残すと判断し（図２３；Ｓ１４０９：ＹＥＳ）、「では、メッセージをお願いします。」等のように応答する。ユーザからメッセージが送信された場合には、そのメッセージを受信し（図２３；Ｓ１４１０）、予約支援サーバ１のＣＰＵ３０は、当該予約情報の予約ＩＤと関連付けて、１人予約をする人に対するメッセージを記憶部１６に記憶する（図２３；Ｓ１４１１）。なお、メッセージを受信した場合には、予約支援サーバ１のＣＰＵ３０は、「メッセージを受け付けました。では当日お楽しみください。」等の応答を行ってもよい。

一方、メッセージを残すかどうかの問合せに対して、「いいえ。」等の否定的なメッセージが送信された場合には、「わかりました。では当日お楽しみください。」等の応答を行ってもよい。

さらに、予約支援サーバ１のＣＰＵ３０は、先に１人予約を行った１人予約者に対して、一緒にゴルフに行くことを了承した別の１人予約者が現れたことを通知する（図２３；Ｓ１４１２）。したがって、本実施形態によれば、１人予約をした者同士が一緒にゴルフを行う機会を与えることができる。

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

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

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

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

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

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

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

次に、予約支援サーバ１のＣＰＵ３０は、１人予約フラグがオン状態であるかどうかを判断するが（図２３；Ｓ１４００）、１人予約フラグがオン状態ではないので（図２３；Ｓ１４００：ＮＯ）、処理を終了させる。

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

＜５−２：１人予約＞
図１７は、１人予約を行う際の端末装置における表示例を示す図である。まず、ユーザが、専用アカウントであるゴルフ予約Ａ１０を会話の相手として選択すると、図１７に示すメッセージ表示画面Ｐ３が表示される。そして、ユーザが「１人で行く」というメッセージＣ８０を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する（図１９；Ｓ９０）。解析の結果、１人予約が行われると判断され、ＣＰＵ３０は、１人予約フラグをオン状態とする（図２２；Ｓ１３０１）。そして、ＣＰＵ３０は、日程が仮登録済みかどうか（図２２；Ｓ１３０２）を判断するが、図１７の場合には、日程は仮登録済みではないので（図２２；Ｓ１３０２：ＮＯ）、ユーザに対して日程の入力を要求するメッセージを送信する（図２２；Ｓ１３０３）。ユーザの端末装置においては、図１７に示すように、「１人予約ですね。行きたい日を数字４ケタで教えてください。」というメッセージＣ８１が表示される。

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

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

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

ユーザが「いいね。」というメッセージＣ８７を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信してその内容を解析する（図１９；Ｓ９０）。解析の結果、提示したゴルフ場が承認されたと判断され、ＣＰＵ３０は、当該ゴルフ場のゴルフ場名とゴルフ場ＩＤとを記憶部１６に記憶させて仮登録を行う（図２１；Ｓ１２０１）。次に、予約支援サーバ１のＣＰＵ３０は、日程が仮登録済みであり（図２１；Ｓ１２０２：ＹＥＳ）、ゴルフ場も仮登録済みであると判断し（図２１；Ｓ１２０４：ＹＥＳ）、枠情報が仮登録済みであるかどうかの判断を行う（図２１；Ｓ１２０６）。枠情報は未だ仮登録が行われていないので（図２１；Ｓ１２０６：ＮＯ）、予約支援サーバ１のＣＰＵ３０は、予約サーバ５にアクセスして、１人予約の可能な空き枠情報を抽出して、ユーザに対して承認を要求するメッセージを送信する（図２１；Ｓ１２０７）。ユーザの端末装置には、図１７に示すように、「８月２５日の１人予約、六本木ＧＣで7:00スタート、7,000円です。」というメッセージＣ８８が表示される。

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

次に、予約支援サーバ１のＣＰＵ３０は、１人予約フラグがオン状態であると判断し（図２３；Ｓ１４００：ＹＥＳ）、１人予約フラグをオフ状態とする（図２３；Ｓ１４０１）。そして、ＣＰＵ３０は、他に１人予約者がいるかどうかを判断し（図２３；Ｓ１４０２）、他に１人予約者がいないと判断した場合には（図２３；Ｓ１４０２：ＮＯ）、ユーザに対してメッセージを残すかどうかの問合せを行う（図２３；Ｓ１４０３）。ユーザの端末装置には、「メッセージを残しますか？」というメッセージＣ９１が表示される。

この問合せに対して、「はい。」等の肯定的なメッセージが送信された場合には、予約支援サーバ１のＣＰＵ３０は、ユーザがメッセージを残すと判断し（図２３；Ｓ１４０３：ＹＥＳ）、「では、メッセージをお願いします。」等のメッセージＣ９３を送信して応答する。ユーザが「２０代女性です。初心者ですけど、月イチくらいで気軽に楽しめるゴルフ友達を探してまーす。」というメッセージＣ９４を送信すると、予約支援サーバ１のＣＰＵ３０は、このメッセージを受信する（図２３；Ｓ１４０４）。そして、ＣＰＵ３０は、このメッセージを予約ＩＤと関連付けて記憶部１６に記憶させる（図２３；Ｓ１４０５）。

次に、他のユーザが、上述したゴルフ場と同じゴルフ場、及び、同じ日を予約日として、１人予約を行った場合について説明する。当該他のユーザが１人予約を完了するまでは、上述した例と同様なので、重複する説明は省略する。

この例では、予約支援サーバ１のＣＰＵ３０は、図１８に示すように、「８月２５日の１人予約、六本木ＧＣで7:10スタート、7,000円です。」という枠情報のメッセージＣ１００を送信し、これに対してユーザが「予約して」というメッセージＣ１０１を送信した場合には、予約サーバ５に対する予約情報の本登録処理を行い、ユーザに対しては、「予約完了しました。」というメッセージＣ１０２を表示させる。

予約支援サーバ１のＣＰＵ３０は、メッセージＣ１０２を表示させた後、１人予約フラグがオン状態であると判断し（図２３；Ｓ１４００：ＹＥＳ）、１人予約フラグをオフ状態にする（図２３；Ｓ１４０１）。そして、予約支援サーバ１のＣＰＵ３０は、１人予約者がいるかどうかを判断するが（図２３；Ｓ１４０２）、この例では図１７に示したような１人予約したユーザがいると判断し（図２３；Ｓ１４０２：ＹＥＳ）、先に１人予約したユーザが残したメッセージを表示させるかどうかを確認するメッセージを送信する（図２３；Ｓ１４０６）。ユーザの端末装置には、図１８に示すように、「既に１人分の予約が入っています。メッセージを見ますか？」というメッセージＣ１０３が表示される。

ユーザが「見る」というメッセージＣ１０４を送信した場合には、予約支援サーバ１のＣＰＵ３０は、メッセージを表示させると判断し（図２３；Ｓ１４０６：ＹＥＳ）、記憶部１６に記憶させておいた先の１人予約者のメッセージと、一緒に行くかどうかを問い合わせるメッセージを送信する。ユーザの端末装置には、「「２０代女性です。初心者ですけど、月イチくらいで気軽に楽しめるゴルフ友達を探してまーす。」とのことです。一緒に行きますか？」と表示させる。

ユーザが「はい」というメッセージＣ１０６を送信した場合には、予約支援サーバ１のＣＰＵ３０は、このユーザが先に１人登録したユーザと一緒にゴルフに行くことを了承し、メッセージを残したユーザが登録されている予約枠に参加すると判断し（図２３；Ｓ１４０７：ＹＥＳ）、予約支援サーバ１のＣＰＵ３０は、先に予約された１人予約者と、上述のように当該１人予約者と一緒にゴルフに行くことを了承した１人予約者との予約情報を関連付ける、予約情報の修正処理を行う（図２３；Ｓ１４０８）。
次に、ＣＰＵ３０は、ユーザに対して、メッセージを残すかどうかを問い合わせる（図２３；Ｓ１４０９）。ＣＰＵ３０は、ユーザが先に１人予約したユーザへのメッセージを残すと判断した場合には（図２３；Ｓ１４０９：ＹＥＳ）、そのメッセージを受信して（図２３；Ｓ１４１０）、受信したメッセージを予約ＩＤと関連付けて記憶部１６に記憶させる（図２３；Ｓ１４１１）。 そして、予約支援サーバ１のＣＰＵ３０は、先に１人予約をしたユーザに対してその旨を通知する（図２２；Ｓ１４１２）

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

また、ユーザから他の１人予約者の情報を表示させることが選択された場合において（図１６；Ｓ１４０６）、情報を表示すべき他の１人予約者が複数いる場合は、応答部１１は、所定の優先順位に従って、表示させるべき他の１人予約者を特定し、当該他の１人予約者についての情報を、端末装置２に送信する。ここで所定の優先順位とは、例えば当該ユーザの予約情報と、ゴルフのスタート時間が最も近い他の１人予約者としたり、当該ユーザの住所に最も近い住所情報を有する他の１人予約者としたり、することができる。
また応答部１１は、情報を表示すべき他の１人予約者が複数いる場合は、当該複数の他の１人予約者にかかる予約内容をリスト状にして、端末装置２に送信することとしてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この日付の情報を受信した予約支援サーバ１のＣＰＵ３０は、メッセージ内容の解析の結果（図１９；Ｓ９０）、日付の入力があったと判断し（図１９；Ｓ２００）、日付を仮登録する（図１９；Ｓ２０１）。この場合、図２７には示していないが、第１実施形態のように、「１０月２７日ですね。」という確認メッセージを表示するようにしてもよい。そして、予約支援サーバ１ａのＣＰＵ３０は、ゴルフ場が仮登録済みかどうかを判断し（図１９；Ｓ２０２）、ゴルフ場が仮登録されていない場合には（図１９；Ｓ２０２：ＮＯ）、住所入力済みかどうかを判断する（図１９；Ｓ２０４）。そして、住所が未入力である場合には（図１９；Ｓ２０４：ＮＯ）、ユーザに対して住所の入力を要求するメッセージを送信する（図１９；Ｓ２０５）。ユーザの端末装置２ａでは、図２７に示すように、「おすすめのゴルフ場を探してみます。位置情報をおしえてください。」というメッセージＣ２０２が表示される。

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

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

予約支援サーバ１のＣＰＵ３０は、都道府県または地域の入力が行われたと判断し（図１９；Ｓ５００）、当該地域におけるお勧めのゴルフ場を検索する旨の確認メッセージを送信する（図１９；Ｓ５０１）。図２７の例では、ユーザの端末装置２ａの表示部２５には、「那須地区で探してみます。」というメッセージＣ２０５が表示される。
予約支援サーバ１ａにおいては、地図画像において選択可能な地域のそれぞれについて、ユーザに対して提示可能なお勧めのゴルフ場の情報が推奨施設情報として予め記憶されており、端末装置２ａから、例えば「那須地区」等の情報が送信された場合には、ＣＰＵ３０は、当該地区のお勧めのゴルフ場の情報を抽出して（図１９；Ｓ５０３）、予約支援サーバ１ａから端末装置２ａに対してお勧めのゴルフ場を表示させ承認を求める（図１９；Ｓ５０３）。そして、このお勧めのゴルフ場の情報を受信した端末装置２ａは、お勧めのゴルフ場の情報を表示させる。

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

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

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

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

＜変形例１＞
上述した第１実施形態においては、予約サーバ５における本登録処理が完了した後に、図２３に示す１人予約処理を実行する例について説明した。しかし、本登録処理の前に１人予約処理を実行するようにしてもよい。図３０は、第１実施形態の図２１に示すフローチャートに対応するフローチャートである。図３０に示すフローチャートは、本登録処理（Ｓ１２０８）の前に１人予約処理（Ｓ１２２０）を実行し、予約完了の表示（Ｓ１２０９）を行った後は、図１９のステップＳ９０に移行するところが図２１に示すフローチャートと異なっている。

また、図３１にこの変形例１における１人予約処理のフローチャートを示す。図３１は、第１実施形態の図２３に示すフローチャートに対応するフローチャートである。図３１の場合には、処理が終了すると、図３０の本登録処理（Ｓ１２０８）の前に戻るところが図２３に示すフローチャートと異なる。また、２人の予約情報を関連付ける際に（Ｓ１４０８）、第１実施形態では、後に１人予約を行った１人予約者が、本登録した予約情報を破棄して、先に１人予約した１人予約者の予約情報に合わせる処理を行った。しかし、この変形例では、後に１人予約を行った１人予約者の予約情報については、まだ本登録を行っていないので、予約情報の破棄という処理を行うことなく、先に１人予約した１人予約者の予約情報に合わせるようにする。そして、この後に本登録処理を行う。このように、この変形例によれば、１人予約者の予約情報のマッチングの際に、予約情報の破棄という処理を省くことが可能になる。

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

＜変形例３＞
さらに、上述した各実施形態では、１人予約の際に、他の１人予約者にメッセージを残す場合と残さない場合を選択可能な例について説明したが、１人予約を行ったという情報を開示しないように設定するようにしてもよい。この変形例３においては、登録部１４は公開設定に関する情報を登録する処理部としての機能をも有する。図３３は、この変形例３における１人予約処理のフローチャートを示す。図２３と異なる部分を中心に説明する。図３３に示すように、この変形例では、１人予約の本登録を行った後に、他の１人予約者がいない場合には（Ｓ１４０２：ＮＯ）、個人情報の公開設定を行う（Ｓ１４２０）。

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

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

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

他の１人予約者がいる場合には（Ｓ１４０２：ＹＥＳ）、ＣＰＵ３０は、当該他の１人予約者に関する予約情報を表示させるかどうかを問いかける（Ｓ１４２３）。この問いかけに、表示させない旨のメッセージが送信された場合（Ｓ１４２３：ＮＯ）、ＣＰＵ３０は、予約処理を完了させる。

一方、表示させる旨のメッセージが送信された場合（Ｓ１４２３：ＹＥＳ）、ＣＰＵ３０は、当該他の１人予約者が設定した公開設定に応じて、予約情報を表示させる。具体的には、他の１人予約者が、公開設定において「１．個人情報は公開しない」を選択していた場合、ＣＰＵ３０は当該予約情報の書誌的事項、例えばスタート時間、スタートホール、料金、のみを端末装置２に送信する。「２．プロフィール公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項に加えて、当該他の１人予約者のプロフィール、例えば氏名、性別や「３０歳台」等の年齢を、端末装置２に送信する。「３．メッセージ公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項に加えて、当該他の１人予約者の残したメッセージを、端末装置２に送信する。「４．プロフィールとメッセージを公開」を選択していた場合、ＣＰＵ３０は、上記予約情報の書誌的事項、プロフィール情報、メッセージを、端末装置２に送信する。

そしてＣＰＵ３０は、かかる他の１人予約者と一緒にラウンドするか否かの選択を求め（Ｓ１４０７）、一緒にラウンドすることが選択されると、上述のようにＣＰＵ３０は予約情報の修正を行う（Ｓ１４０８）。そして、ＣＰＵ３０は、公開設定を行い（Ｓ１４２４）、メッセージがある場合はメッセージとともに公開設定を記憶し（Ｓ１４２５）、メッセージがない場合は公開設定を記憶する（Ｓ１４２６）。この公開設定及び記憶する処理はステップＳ１４２０、ステップＳ１４２１、ステップＳ１４２２で行った処理と同様であるので説明を省略する。

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

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

＜変形例５＞
上述した実施形態及び変形例においては、仮登録情報は常に保存しておく例について説明したが、本発明はこのような例に限定されるものではなく、所定時間経過した仮登録情報については、リセットするようにしてもよい。
例えば同じユーザが、チャットにメッセージを投稿すると、ＣＰＵ３０は、チャット履歴テーブル１６ａを参照して、今回の投稿の受付日時と、前回の最後の投稿の受付日時の比較を行う。この比較の対象になる最後の投稿には、専用アカウントによる最後の投稿と、ユーザによる最後の投稿の双方を含む。そして、ＣＰＵ３０は、前回のチャット終了（中断）時から所定時間、例えば１週間経過していると判断した場合には、応答メッセージとして、「前回までの経過はリセットされました。」を送信し、続けて「ゴルフの予約ですね。行きたい日を数字４ケタで教えてください。」等のメッセージを送信する。
なお、最終の投稿から３日経過して、リセット期限である１週間を経過する前（例：５日目）にユーザがメッセージを送ってきた場合には、ＣＰＵ３０は、「前回の処理を継続しますか？」と尋ねてもよい。そしてＣＰＵ３０は、「はい」を受信すると、前回の処理内容をチェックし、例えば、ゴルフ場だけ決まっていない場合等、処理が途中で終わっていれば、そこから処理を再開する。一方、予約の本登録まで終了している場合は、ＣＰＵ３０は、「前回の予約が完了しているので新規になります。」などと応答する。
ここで、ＣＰＵ３０は、予め前回の処理内容をチェックし、途中で終わっている場合のみ「前回の処理を継続しますか？」と尋ねるようにしてもよい。この方がユーザにとって応答の煩雑さは減少する。

＜変形例６＞
上述した各実施形態および変形例では、メッセージ送受信サービスで使用するユーザアカウントと、予約サーバ５へログインを行うためのログイン情報とが異なっていたが、これを一致させることとしてもよい。具体的には、メッセージ送受信サービスで使用するユーザアカウントを、予約サーバ５へログインするためのログイン情報としても使用できるように、予約サーバ５に照合のために記憶されるログイン情報を構成する。そして、仮登録情報を本登録するときにユーザに対して要求される、予約サーバ５へのログイン情報の入力作業を省略し、本登録を行う際に予約支援サーバ１が当該ユーザのログイン情報を予約サーバ５へ送信してログイン処理を行い、更に仮登録情報を送信して予約サーバ５において本登録を行う構成とする。

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

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

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

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

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

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

ＮＥＴ……通信網、１，１ａ……予約支援サーバ、２，２ａ……端末装置、３……外部管理サーバ、４……マップサーバ、５……予約サーバ、１０……解析部、１１……応答部、１２……判断部、１３……応答制御部、１４……登録部、１５……候補提示部、１６……記憶部、１７……宛先検出部、１８……予約検出部、２１……取得部、２２……入力部、２３……表示制御部、２４……変換部、２５……表示部、２６……記憶部。

Claims (10)

1. ユーザの使用に係る端末装置と、当該端末装置と通信可能な予約支援装置とを備える予約支援システムであって、
   前記予約支援装置は、
   前記端末装置における入力の内容を解析する解析部と、
   前記解析部における解析結果に応じて所定の内容を応答する応答部と、
   所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断する判断部と、
   前記判断部により前記予約に必要な情報が充足されていないと判断された場合に、前記必要な情報の入力を促す内容を前記応答部により応答させる応答制御部と、
   前記判断部により前記予約に必要な情報が充足されたと判断された場合に、前記予約に必要な情報を登録する登録部とを備え、
   前記端末装置は、
   画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部と、
   前記ユーザによる操作に応じて、前記取得部で取得された前記画像を表示させる表示制御部と、
   前記ユーザによる操作に応じて情報を入力可能な入力部と、
   前記入力部を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記解析部により解析可能な内容に変換する変換部とを備える、
   ことを特徴とする予約支援システム。
2. 前記端末装置は、画像の選択によって日付情報の入力が可能な機能が付加されたカレンダー画像を取得可能な取得部をさらに備え、
   前記表示制御部は、前記ユーザによる操作が日付の入力に関する操作である場合には、前記カレンダー画像を表示させ、
   前記変換部は、前記入力部を介して前記カレンダー画像における日部分の画像の選択による日付情報の入力が行われた場合には、当該日付情報を日付についての文字情報に変換することを特徴とする請求項１に記載の予約支援システム。
3. 前記端末装置は、画像の選択によって場所情報の入力が可能な機能が付加された地図画像を取得可能な取得部をさらに備え、
   前記表示制御部は、前記ユーザによる操作が場所の入力に関する操作である場合には、前記地図画像を表示させ、
   前記変換部は、前記入力部を介して前記地図画像の選択による場所情報の入力が行われた場合には、当該場所情報を場所についての文字情報に変換することを特徴とする請求項１または請求項２に記載の予約支援システム。
4. 前記予約支援装置は、予め都道府県または都道府県より狭い範囲の地域に対応する推奨アクティビティ施設に関する推奨施設情報を記憶しており、
   前記端末装置において前記地図画像の選択による場所情報の入力が行われた場合、当該入力した場所情報に対応する都道府県または地域の推奨施設情報を前記予約支援装置から受信可能であること特徴とする、請求項３に記載の予約支援システム。
5. 画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部と、
   前記ユーザによる操作に応じて、前記取得部で取得された前記画像を表示させる表示制御部と、
   前記ユーザによる操作に応じて情報を入力可能な入力部と、
   前記入力部を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置により解析可能な内容に変換する変換部とを備える、
   ことを特徴とする端末装置。
6. 前記端末装置は、前記端末装置での入力内容に応答する機能を有する予約支援装置と通信が可能であり、
   前記取得部は、画像の選択によって日付情報の入力が可能な機能が付加されたカレンダー画像を取得可能であり、
   前記表示制御部は、前記ユーザによる操作が日付の入力に関する操作である場合には、前記カレンダー画像を表示させ、
   前記変換部は、前記入力部を介して前記カレンダー画像における日部分の画像の選択による日付情報の入力が行われた場合には、当該日付情報を日付についての文字情報に変換することを特徴とする請求項５に記載の端末装置。
7. 前記端末装置は、前記端末装置での入力内容に応答する機能を有する予約支援装置と通信が可能であり、
   前記取得部は、画像の選択によって場所情報の入力が可能な機能が付加された地図画像を取得可能であり、
   前記表示制御部は、前記ユーザによる操作が場所の入力に関する操作である場合には、前記地図画像を表示させ、
   前記変換部は、前記入力部を介して前記地図画像の選択による場所情報の入力が行われた場合には、当該場所情報を場所についての文字情報に変換することを特徴とする請求項５に記載の端末装置。
8. ユーザの端末装置を用いた予約を支援する予約支援方法であって、
   前記端末装置における入力の内容を解析し、
   前記解析の結果に応じて所定の内容を応答し、
   所定のアクティビティに関する予約に必要な情報が充足されたか否かを判断し、
   前記予約に必要な情報が充足されていないと判断された場合に、前記必要な情報の入力を促す内容を応答し、
   前記予約に必要な情報が充足されたと判断された場合に、前記予約に必要な情報を登録し、
   画像の選択によって情報の入力が可能な機能が付加された画像を取得し、
   前記ユーザによる操作に応じて、前記取得した前記画像を表示し、
   前記ユーザによる操作に応じて情報を入力し、
   前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記解析が可能な内容に変換する、
   ことを特徴とする予約支援方法。
9. ユーザの使用に係る端末装置と、当該端末装置と通信可能な予約支援装置とを備える予約支援システムにおける前記端末装置の制御方法であって、
   画像の選択によって情報の入力が可能な機能が付加された画像を取得し、
   前記ユーザによる操作に応じて、前記取得部で取得された前記画像を表示させ、
   前記ユーザによる操作に応じて情報を入力し、
   前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置により解析可能な内容に変換する、
   ことを特徴とする端末装置の制御方法。
10. ユーザの使用に係る端末装置と、当該端末装置と通信可能な予約支援装置とを備える予約支援システムにおけるコンピュータを備える前記端末装置のプログラムであって、
    前記コンピュータを、
    画像の選択によって情報の入力が可能な機能が付加された画像を取得する取得部と、
    前記ユーザによる操作に応じて、前記取得部で取得された前記画像を表示させる表示制御部と、
    前記ユーザによる操作に応じて情報を入力可能な入力部と、
    前記入力部を介して前記画像の選択による情報の入力が行われた場合には、当該入力の内容を前記予約支援装置により解析可能な内容に変換する変換部として機能させる、
    ことを特徴とする端末装置のプログラム。

Images