JP2012138003A - 予約サーバ - Google Patents

Abstract

【課題】プレー等に必要な人数を満たさなくても予約を許容している予約システムにおいて、望まない者と編成されることをできるだけ防止する予約サーバを提供する。
【解決手段】予約者が望まない会員に対して案内メールが送信されないよう、予約サーバにおける記憶部の情報連係データベースを参照し、予約実行処理における予約者とメール送信対象者との間で情報連係が「否」として設定されているかどうかを判定し、「否」として設定されているメール送信対象者をメール送信対象者群から削除する（Ｓ１４５）。
【選択図】図２

Description

本発明は、一定数以上の人が集まって行うスポーツやイベント等の予約を行う予約サーバに関する

一定数以上の人が集まって行うスポーツやイベント等が存在する。一例としてはゴルフが挙げられるが、ゴルフの場合、３人又は４人から構成されるパーティの単位でないとゴルフ場のコースの予約申し込みができないことが通常である。

しかし、そのような制限があると、１人で（同伴者を特定せずに）ゴルフコースを予約したいというニーズを満たすことができず、ゴルフ場としては収益機会の喪失となっていた。なお、このニーズは、ゴルフ場又は予約仲介者によって同伴者を紹介又は募集して欲しいというニーズとも言い換えられる。

このようなニーズに応える予約システムとして、下記の特許文献１に示された予約システムが知られている。この予約システムは、１人での予約を許容し、予約があった際に当該ゴルフ場の会員データベースの中からその予約者と過去に同じパーティでプレーした者を選択（検索）するものである。そして、その選択した会員に対して自動的に案内メールを送信し、その案内に応じた者同士でパーティを編成するものである。
特開２００２−３１２５３０号公報

ところが、このような予約システムであると次のような問題が生ずるおそれがある。例えば、過去に同じパーティでプレーした際にトラブルとなった相手に対しても案内メールが送られてしまうことが起こり得る。また、過去に同じパーティでプレーした際にあまりに技能の程度に差があることがわかり次回以降は同じパーティでプレーしたくないと思っていた相手にもかかわらず、その人に案内メールが送られてしまうことが起こり得る。このようなことが起こると、予約者側としては予約をためらうことにつながり、ゴルフ場側としては収益機会の損失につながる。

本発明はこのような問題にかんがみなされたものであり、プレー等に必要な人数に満たさなくても予約を許容している予約システムにおいて、望まない者とパーティ等が編成されることをできるだけ防止できる予約サーバを提供することを目的とする。

上記課題を解決するためになされた第１の予約サーバは、予約対象事項に想定されている所定の人数単位に達しない単位での予約を受け付ける受付手段と、前記受付手段が受け付けた予約の対象者に関する過去の予約履歴情報を取得する予約履歴報取得手段と、前記予約履歴情報取得手段が取得した前記予約履歴情報に基づき、前記予約の対象者と過去に同一の予約対象事項を共にした者に対して案内を通知する通知手段と、前記通知手段による前記案内の通知を行わない対象者であるか否かを判定する判定手段と、を備える。そして、前記通知手段は、前記判定手段により前記案内の通知を行わない対象者であると判定された対象者に対して、前記案内の通知を行わない。

このような予約サーバによれば、予約者が望まない者に対して案内の通知を行わないと判定されるよう構成されていることにより、案内の通知を行わないと判定された対象者に対して案内の通知が行われない。このため、望まない者とパーティ等が編成されることを防止できる。なお、判定は、例えば、予約者毎に案内を望まない者の情報が記録されたリストに基づいて行ったり、逆に、予約者毎に案内を望む者の情報が記録されたリストに基づいて行ったりするとよい。

また、第２の予約サーバは、前記通知手段による前記案内の通知を行わない対象者であるか否かを予約者が設定するための設定手段をさらに備え、前記判定手段は、前記設定手段によって設定された結果に基づいて前記判定を行うことを特徴とする。

このような予約サーバによれば、予約者が直接、案内の通知を行わない対象者を設定できるため、より予約者の希望が反映された判定が行われる。
また、第３の予約サーバは、指定されたアドレス情報に基づいて、特定の予約者のプロフィール情報を提示する予約者情報提示手段をさらに備え、前記アドレス情報には有効期限が特定可能な情報が含まれており、前記予約者情報提示手段は、前記有効期限を特的可能な情報に基づいて前記プロフィール情報の提示可否を決定することを特徴とする。

このような予約サーバによれば、ある時点で、他予約者のプロフィール情報のアドレス情報を知っていたとしても、そのアドレス情報の有効期限が経過すれば、新たに最新の（少なくとも有効期限の切れていない）アドレス情報を入手しない限り、その予約者のプロフィール情報を入手（閲覧）できない。このため、プライバシーの度合いが向上する。

実施形態の予約システムの全体構成を示す図である。 予約実行処理を説明するためのフローチャートである。 予約対象のプランを説明する画面の一例である。 予約に必要な情報を入力するための画面の一例である。 予約完了画面である。 情報連係設定処理を説明するためのフローチャートである。 プロフィール（詳細）を閲覧する他会員を指定するための画面の一例である。 メールつながり設定を変更するための画面の一例である。 他会員画面送信処理を説明するためのフローチャートである。 他会員のプロフィール画面の一例である。

以下、本発明が適用された実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。

［構成の説明］
図１は、本発明の実施形態である予約システム１の全体構成を示す説明図である。予約システム１は、ゴルフコースの予約を実現するためのシステムであり、主に、予約サーバ３と、ＰＣ５ａ，５ｃ，…（以下、単に「ＰＣ５」と記す。）と、公衆回線７とから構成される。

予約サーバ３は、周知のサーバであり、液晶ディスプレイ等からなる表示部、キーボード・マウス等からなる操作部、ＣＰＵ，ＧＰＵ，ＲＡＭ等からなる演算部、ＨＤＤ，ＳＳＤ等からなる記憶部、及び、ネットワークインターフェイスからなる通信部を備える。なお、記憶部には、Ｗｅｂサーバプログラム、データベース管理プログラム、及びデータベースファイルが記憶されており、これらが演算部に読み出されて各種の処理が実行される。具体例としては、ＰＣ５からのＨＴＴＰリクエストに応じ、Ｗｅｂサーバプログラムが、データベース管理プログラムを介してデータベースにアクセスして様々な情報を取得し、ＨＴＭＬファイルを動的に作成して、その作成したＨＴＭＬファイルをＰＣ５へ送信する。なお、データベースとしては、会員情報が蓄積された会員データベース、ゴルフコース毎の予約枠に関する情報が記憶されている予約データベース、会員間の情報連係に関する情報を記憶する情報連係データベース等が存在する。

ＰＣ５は、周知のパーソナルコンピュータであり、液晶ディスプレイ等からなる表示部、キーボード・マウス等からなる操作部、ＣＰＵ，ＧＰＵ，ＲＡＭ等からなる演算部、ＨＤＤ，ＳＳＤ等からなる記憶部、及び、ネットワークインターフェイスからなる通信部を備える。なお、記憶部には、Ｗｅｂブラウザのプログラムが記憶されており、演算部に読み出されて実行されるように構成されている。

公衆回線７は、インターネット等の広域ネットワークであり、予約サーバ３とＰＣ５との間の通信路を提供する。
［動作の説明］
次に、予約サーバ３が実行する処理のうち、本発明に関連する処理について説明する。

（１）予約実行処理
図２は、予約サーバ３が実行する予約実行処理を説明するためのフローチャートである。この予約実行処理は、本処理に先立ちＰＣ５へ提供したＷｅｂページ（例えば、図３，図４）において予約操作がなされ、予約情報とともに予約を意味する指令がＰＣ５から予約サーバ３へ送信され、これらを予約サーバ３が受信した際に実行が開始される。

予約サーバ３のＣＰＵは、予約実行処理の実行を開始すると、ＰＣ５から送信されてきた予約情報を検証する（Ｓ１０５）。ここでいう予約情報というのは、予約者を識別するための情報（会員ＩＤ）、予約対象のゴルフコースを識別するための情報、予約対象のプレー日時等からなる情報である。また、検証というのは、予約者が予約システム１において予め登録されている正規の者であるかどうか、予約対象のゴルフコースにおいて予約対象のプレー日時に空きがあるかどうか等を調べることである。なお、検証の際には、予約サーバ３における記憶部の会員データベース及び予約データベースが参照される。

続いて予約サーバ３のＣＰＵは、検証結果に応じて処理を分岐する（Ｓ１１０）。具体的には、検証結果が「問題なし」であればＳ１２０へ処理を移行させ、検証結果が「問題なし」でない、すなわち、「問題あり」であればＳ１１５へ処理を移行させる。

検証結果が「問題なし」でないとして移行したＳ１１５では、エラー画面（予約情報に何らかの問題があった旨を示す画面）を構成するＨＴＭＬファイル等をＰＣ５へ送信し、本処理（予約実行処理）を終了する。

一方、検証結果が「問題なし」であるとして移行したＳ１２０では、予約情報に基づいて予約登録を行う。具体的には、予約サーバ３における記憶部の予約データベースに予約情報を書き込む。

続いて、予約サーバ３のＣＰＵは、予約完了画面（例えば、図５）を構成するＨＴＭＬファイル等をＰＣ５へ送信する（Ｓ１２５）。
続いて、予約サーバ３のＣＰＵは、予約対象のゴルフコースにおいて予約対象のプレー日時にさらに空きがあるかどうかを判定する（Ｓ１３０）。具体的には、予約人数が１人〜３人であるか（空きがあるか）、４人であるか（空きがないか）を判定する。判定の結果、空きがあると判定した場合はＳ１３５へ処理を移行させ、空きがないと判定した場合は本処理（予約実行処理）を終了する。

空きがあると判定した場合に進むＳ１３５では、予約サーバ３のＣＰＵは、予約者の過去の予約情報を検索する。これは、予約サーバ３における記憶部の予約データベースより、本予約実行処理における予約者が過去に予約した際の予約情報を検索することである。

続いて、予約サーバ３のＣＰＵは、Ｓ１３５で検索された過去の予約情報に基づき、メール送信者対象者を記憶部の予約データベースから検索する（Ｓ１４０）。これは、本予約実行処理における予約者が過去にパーティを組んだ者を検索することであり、具体的には、過去に予約したゴルフコースとそのゴルフコースのプレー日時の両方が同じである他の予約者の予約情報を検索し、会員ＩＤを特定することである。

続いて、予約サーバ３のＣＰＵは、Ｓ１４０で検索されたメール送信対象者群から、情報連係が「否」となっている対象者を削除する（Ｓ１４５）。これは、予約サーバ３における記憶部の情報連係データベースを参照し、本予約実行処理における予約者とメール送信対象者との間で、少なくとも一方の情報連係情報が「否」として設定されているかどうかを判定し、「否」として設定されているメール送信対象者は、Ｓ１４０で検索されたメール送信対象者群から削除することである。なお、「情報連係情報」というのは、設定操作をする側（設定操作元）の会員ＩＤと、設定操作をされる側（設定対象）の会員ＩＤと、情報連係有無に関する情報である。また、上述した「少なくとも一方の情報連係情報が「否」として設定されているかどうか判定し」というのは、例えば、会員Ａの予約に基づき会員Ｂがメール送信対象者として選ばれている場合、会員Ａの会員Ｂに対する情報連係有無、及び、会員Ｂの会員Ａに対する情報連係有無のどちから一方でも「否」であるかどうかを判定するということである。

続いて、予約サーバ３のＣＰＵは、削除後に残ったメール送信対象者群に対して案内メールを送信する（Ｓ１５０）。この案内メールに含まれる内容は、本予約実行処理における予約者と、その予約対象者が予約したゴルフコースと、プレー日時とを示す情報と、当該ゴルフコースの当該プレー日時のパーティへの参加を案内するものである。なお、メール送信対象者群に対象者が一人もいなければメール送信をしないことは言うまでもない。

対象者全員に対して案内メールの送信を終了すると、本処理（予約実行処理）を終了する。
（２）情報連係設定処理
図６は、予約サーバ３が実行する情報連係設定処理を説明するためのフローチャートである。この情報連係設定処理は、例えば図７に示すような、ＰＣ５の表示部に表示されるマイプロフィールページ中の「この人との設定をする」というリンクがクリックされた際に予約サーバ３において実行が開始される。

予約サーバ３のＣＰＵは、情報連係設定処理の実行を開始すると、ＰＣ５から指定されたＵＲＬ情報に基づき、特定の会員の情報連係設定画面を送信する（Ｓ２０５）。一例としては、図８のような画面である。「この人とのメールつながり設定」という欄に「する（予約を知らせる・予約を受け取る）」というオプションボタンと「しない（予約を知らせない・予約を受け取らない）」というオプションボタンがあることが確認できる。

続いて、予約サーバ３のＣＰＵは、ＰＣ５から情報連係設定情報が送信されてくるのを待ち、ＰＣ５から情報連係設定情報が送信されてくるとその情報を受信する（Ｓ２１０）。ここでいう「情報連係設定情報」というのは、設定操作をする側（設定操作元）の会員ＩＤと、設定操作をされる側（設定対象）の会員ＩＤと、情報連係有無に関する情報である。

続いて、予約サーバ３のＣＰＵは、ＰＣ５から受信した情報連係設定情報を記憶部の情報連係データベースに登録／更新を行う（Ｓ２１５）。なお、情報連係データベースのレコードは、例えば、設定操作元の会員ＩＤと、設定対象の会員ＩＤと、情報連係有無に関する情報（「正」，「否」）等からなる。

予約サーバ３のＣＰＵは、情報連係設定情報を情報連係データベースへ登録／更新すると本処理（情報連係設定処理）を終了する。
（３）他会員画面送信処理
図９は、予約サーバ３が実行する他会員画面送信処理を説明するためのフローチャートである。この他会員画面送信処理は、例えば図７に示すような、ＰＣ５の表示部に表示される、マイプロフィールページに表示される「この人の詳細」というリンクがクリックされた際に予約サーバ３において実行が開始される。

予約サーバ３のＣＰＵは、他会員画面送信処理の実行を開始すると、ＰＣ５より指定されたＵＲＬに含まれる引数の一つから日時情報を抽出する（Ｓ３０５）。例えば、ＵＲＬが“http://www.valuegolf.co.jp/one/member.cfm?pid=xxxxx&rent#cid=xxxxx&o#mb#id=xxxxx”であった場合、“o#mb#id=”の後に存在する引数の値を復号化して日時情報を取り出す。

続いて、予約サーバ３のＣＰＵは、Ｓ３０５で抽出した日時情報を現在日時と比較した差分時間が所定時間内か否かを判定する（Ｓ３１０）。所定時間としては、例えば、１時間でもよいし３日でもよく、任意の時間を予約サーバ３の管理者が設定すればよい。

予約サーバ３のＣＰＵは、差分時間が所定期間内であると判定した場合は、Ｓ３１５へ処理を移行し、差分時間が所定期間内でない、すなわち所定期間外であると判定した場合は、Ｓ３２０へ処理を移行する。

差分時間が所定期間内であると判定した場合に進むＳ３１５では、ＰＣ５より指定されたＵＲＬに対応する画面に対し、新たな日時情報が引数に含まれたＵＲＬを対応付けて送信する。そして、本処理（他会員画面送信処理）を終了する。

一方、有効期限は無効であると判定した場合に進むＳ３２０では、エラー画面を送信し、本処理（他会員画面送信処理）を終了する。
［実施形態の効果］
上記実施形態の予約システム１によれば、情報連係（予約を知らせるメールの送信）を望まない会員について、例えば、図８のような画面において、予約を知らせないように設定（情報連係を「否」に設定）しておくことにより、ゴルフコースを予約した際、過去に一緒にゴルフコースを回った会員の中で望まない会員に対して案内メールの送信がなされない。このため、予約者が望まない会員とパーティが編成されることを防止できる。

また、上記実施形態の予約システム１によれば、ある時点で、他の会員のプロフィール画面を閲覧でき、そのプロフィール画面のＵＲＬをブックマークに入れておいたとしても、そのＵＲＬの有効期限を経過すれば、新たに最新の（少なくとも有効期限の切れていない）ＵＲＬを入手しない限り、その予約者のプロフィール画面を閲覧することができない。このため、プライバシーの度合いが向上する。

［他の実施形態］
上記実施形態の予約システム１では、予約実行処理の際、予約サーバ３における記憶部の情報連係データベースを参照し、本予約実行処理における予約者とメール送信対象者との間で、少なくとも一方の情報連係情報が「否」として設定されているかどうかを判定し、「否」として設定されているメール送信対象者は、Ｓ１４０で検索されたメール送信対象者群から削除して案内メールの送信がなされないようになっていた。

ところで、このような情報連係情報は、図７のようなマイページにおける「あなたと過去１年間に一緒にプレーした人」の欄に表示される対象者の選択にも用いられるとよい。具体的には、ＰＣ５から要求に基づき、図７のようなマイページを予約サーバ３が構成する際、「あなたと過去１年間に一緒にプレーした人」に表示する対象者を、次のように選択するとよい。

まず、予約サーバ３のＣＰＵは、マイページとして表示しようとしている会員（すなわち、マイページのオーナー。以下、「表示会員」という。）の過去のプレー情報を検索する。これは、予約サーバ３における記憶部の予約データベースより、表示会員が過去に予約して取り消されることのなかった予約情報を検索することである。

続いて、予約サーバ３のＣＰＵは、過去のプレー情報に基づき、表示会員とパーティを組んだ会員（以下、「表示対象会員」という。）を予約データベースから検索する。具体的には、過去１年間に予約したゴルフコースとそのゴルフコースのプレー日時の両方が同じである他の会員の予約情報を予約データベースから検索し、会員ＩＤを特定することである。

続いて、予約サーバ３のＣＰＵは、特定した表示対象会員から、情報連係が「否」となっている会員ＩＤを削除する。これは、予約サーバ３における記憶部の情報連係データベースを参照し、表示会員と、表示対象会員との間で、少なくとも一方の情報連係情報が「否」として設定されているかどうかを判定し、「否」として設定されている表示対象会員ＩＤを削除することである。なお、上述した「少なくとも一方の情報連係情報が「否」として設定されているかどうか判定し」というのは、例えば、会員Ａのマイページに会員Ｂが過去１年間に一緒にプレーした人として選ばれている場合、会員Ａの会員Ｂに対する情報連係有無、及び、会員Ｂの会員Ａに対する情報連係有無のどちらか一方でも「否」であるかどうかを判定するということである。

続いて、予約サーバ３のＣＰＵは、削除後に残った表示対象会員が、マイページにおける「あなたと過去１年間に一緒にプレーした人」として表示されるようにページを構成する。

このようにマイページを構成することにより、望まない会員の情報がマイページに表示されないようにすることができる。また、自身が表示されることを望まない他会員のマイページに自身が表示されないようにすることもできる。

［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲に記載した用語との対応を示す。
予約実行処理におけるＳ１２０の処理内容が受付手段としての機能に相当し、予約実行処理におけるＳ１３５の処理内容が予約履歴情報取得手段としての機能に相当し、予約実行処理におけるＳ１４０及びＳ１５０が通知手段としての機能に相当し、予約実行処理におけるＳ１４５が判定手段としての機能に相当する。

また、情報連係設定処理の処理内容が設定手段としての機能に相当し、他会員画面送信処理の処理内容が予約者情報提示手段としての機能に相当する。

１…予約システム、３…予約サーバ、５…ＰＣ、７…公衆回線。

Claims (3)

1. 予約対象事項に想定されている所定の人数単位に達しない単位での予約を受け付ける受付手段と、
   前記受付手段が受け付けた予約の対象者に関する過去の予約履歴情報を取得する予約暦報取得手段と、
   前記予約履歴情報取得手段が取得した前記予約履歴情報に基づき、前記予約の対象者と過去に同一の予約対象事項を共にした者に対して案内を通知する通知手段と、
   前記通知手段による前記案内の通知を行わない対象者であるか否かを判定する判定手段と、
   を備え、
   前記通知手段は、前記判定手段により前記案内の通知を行わない対象者であると判定された対象者に対して、前記案内の通知を行わないこと、
   を特徴とする予約サーバ。
2. 請求項２に記載の予約サーバにおいて、
   前記通知手段による前記案内の通知を行わない対象者であるか否かを予約者が設定するための設定手段をさらに備え、
   前記判定手段は、前記設定手段によって設定された結果に基づいて前記判定を行うこと、
   を特徴とする予約サーバ。
3. 請求項１又は請求項２に記載の予約サーバにおいて、
   指定されたアドレス情報に基づいて、特定の予約者のプロフィール情報を提示する予約者情報提示手段をさらに備え、
   前記アドレス情報には有効期限を特定可能な情報が含まれており、
   前記予約者情報提示手段は、前記有効期限を特定可能な情報に基づいて前記プロフィール情報の提示可否を決定すること、
   を特徴とする予約サーバ。