以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、情報処理システムに対して本発明を適用した場合の実施形態である。
[1.情報処理システムの構成及び機能概要]
先ず、本実施形態に係る情報処理システムSの構成及び機能概要について、図1を用いて説明する。図1は、本実施形態に係る情報処理システムSの概要構成の一例を示す図である。
図1に示すように、情報処理システムSは、宿泊施設予約サーバ1と、決済サーバ2と、複数の宿泊施設端末3と、複数のユーザ端末4と、を含んで構成されている。そして、宿泊施設予約サーバ1と、決済サーバ、宿泊施設端末3及びユーザ端末4とは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP等を用いて相互にデータの送受信が可能になっている。なお、ネットワークNWは、例えば、インターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。
宿泊施設予約サーバ1は、宿泊施設予約サイトに関する各種処理を実行するサーバ装置である。宿泊施設予約サーバ1は、本発明における情報処理装置の一例である。宿泊施設予約サイトは、宿泊施設の宿泊の予約の受け付けを行うWebサイトである。宿泊施設予約サイトは、複数の宿泊施設から予約の受け付けを委託されている。宿泊施設予約サーバ1は、ユーザ端末4からのリクエストに応じて、例えば、宿泊施設予約サイトのWebページを送信したり、宿泊施設の検索や、宿泊の予約等に関する処理を行ったりする。また、宿泊施設予約サーバ1は、決済サーバ2へリクエストを送信することにより、例えば、クレジットカードの有効性を確認したり、宿泊施設の宿泊料金の決済する処理を行ったりする。
決済サーバ2は、クレジットカードでの決済に関する各種処理を実行するサーバ装置である。決済サーバ2は、宿泊施設予約サーバ1からのリクエストに基づいて、例えば、クレジットカードの与信の承認の判定を行ったり、決済の処理を行ったりする。なお、図1は、一台の決済サーバ2のみを示しているが、例えば、宿泊施設予約サイトにおいて利用可能なクレジットカードの発行元のクレジットカード会社ごとに決済サーバ2が設けられている。
宿泊施設端末3は、宿泊施設予約サイトに予約の委託をしている宿泊施設の提供者が利用する端末装置である。宿泊施設端末3は、提供者からの操作に基づいて宿泊施設予約サーバ1等のサーバ装置にアクセスする。これにより、宿泊施設端末3は、サーバ装置からWebページを受信して表示する。宿泊施設端末3には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。提供者は、宿泊施設端末3を利用することにより、例えば、宿泊施設の情報を宿泊施設予約サイトに登録したり、宿泊施設の予約状況を確認したりする。
ユーザ端末4は、宿泊施設予約サイトを利用するユーザの端末装置である。ユーザ端末4は、ユーザからの操作に基づいて宿泊施設予約サーバ1にアクセスすることにより、宿泊施設予約サーバ1からWebページを受信して表示する。ユーザ端末4には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末4としては、例えば、パーソナルコンピュータ、PDA(Personal Digital Assistant)、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
[2.オンラインカード決済での予約]
ユーザは、宿泊施設予約サイトで宿泊施設の利用を予約するとき、宿泊施設の決済方法を指定することができる。決済方法としては、現地決済とオンラインカード決済とがある。現地決済においては、ユーザが、宿泊施設にチェックインするときやチェックアウトするときに、宿泊施設で決済を行う。このとき、ユーザは、例えば、現金決済やクレジットカード決済等を選択することができる。オンラインカード決済では、ユーザが指定したクレジットカードで宿泊施設予約サーバ1が宿泊料金を決済する。本実施形態において、オンラインカード決済の決済日は、チェックアウト日の翌日である。オンラインカード決済で決済された宿泊料金は、例えば、宿泊施設予約サイトから宿泊施設の口座へ振り込まれる。ユーザは、オンラインカード決済を指定した場合、宿泊施設を利用した際に宿泊施設で決済の手続を行わないで済ませることができる。なお、オンラインカード決済の決済日は、チェックアウト日の翌日に限られるものではない。オンラインカード決済の決済日は、チェックイン日以降の何れかの日であればよい。チェックイン日以降とは、チェックイン日と、チェックイン日よりも後の日とを含む。
ユーザがオンラインカード決済を指定して予約を要求した場合、宿泊施設予約サーバ1は、ユーザから指定されたクレジットカードの有効性を確認する。その理由は、指定されたクレジットカードで宿泊料金の支払い能力がユーザにあるかを判断するためである。また、宿泊料金に相当する与信枠を確保するためである。クレジットカードの有効性の確認には、ユーザが指定したクレジットカードの情報が、正規に発効されたクレジットカードの情報と一致するか否かの確認、クレジットカードの有効期限が切れていないかの確認、現時点でのクレジットカードの利用可能額が宿泊料金以上であるか否かの確認を含む。クレジットカードの利用可能額とは、クレジットカードの利用限度額から、現在確保されている与信枠に相当する金額を差し引いて得られる額である。クレジットカードの有効性を確認する処理は、オーソリ処理と呼ばれている。オーソリは、Authorizationの略語である。本実施形態においては、クレジットカードの有効性を確認することを、クレジットカードの与信を確認するという。与信を確認することができると、指定されたクレジットカードで利用代金の支払いに対する信用が与えられる。つまり、与信枠に相当する金額を決済することが可能であることが保証される。ただし、確認された与信は所定の期間のみ有効であり、所定の期間を過ぎると無効となる。この期間が与信期間である。与信期間は、クレジットカードでの支払いの信用が与えられる期間である。与信期間が経過すると、確保された与信枠が消滅する。与信期間の日数は予め定められている。例えば、本実施形態において、与信期間の日数は30日である。しかしながら、与信期間の日数は、30日以外であってもよい。
予約時に与信を確認することができなかった場合、宿泊施設予約サーバ1は、このままではオンラインカード決済で宿泊料金を決済することができない。しかしながら、ユーザが指定したクレジットカードの情報が、予約時において有効なクレジットカードの情報であったとしても、与信を確認することができない場合がある。上述したように、宿泊料金がクレジットカードの利用可能額を超える場合である。つまり、ユーザが予約しようとした月のクレジットカードの利用額が大きくなってしまった場合である。この場合に、宿泊施設予約サーバ1が、ユーザから指定されたクレジットカードでのオンラインカード決済による予約を受け付けないと、ユーザにとって不便である。また、ユーザは、宿泊施設予約サイトでの予約自体をやめてしまう場合がある。すると、予約が行われなかった分、宿泊施設の提供者は、宿泊施設の提供の機会を失ってしまう。
情報処理システムSにおいては、予約時にクレジットカードの与信を確認することができなかった場合でも、宿泊施設予約サーバ1は、予約を受け付ける。このとき、宿泊施設予約サーバ1は、ユーザから指定されたクレジットカードの情報を記憶しておく。その後、宿泊施設予約サーバ1は、記憶しておいたクレジットカードの情報に基づいて、与信確認を再度行う。2回目の与信確認を、「再与信確認」という。宿泊施設予約サーバ1は、再与信確認において与信を確認することができた場合には、決済方法を、ユーザが予約時に指定したクレジットカードによるオンラインカード決済とすることを示す情報を出力する。一方、宿泊施設予約サーバ1は、与信を確認することができなかった場合には、受け付けた予約を維持しつつ、ユーザが予約時に指定したクレジットカードによるオンラインカード決済とは異なる方法にすることを示す情報を出力する。
宿泊施設予約サーバ1が再与信確認を行う理由は、予約の時点では宿泊料金をクレジットカードで決済する信用がなかったとしても、その後信用が回復する場合があるからである。例えば、月に1回、過去の1ヶ月の間に決済の処理が行われた与信枠がクリアされる日がある。与信枠がクリアされる日を「与信枠クリア日」という。実際には、例えば、与信枠クリア日の前日から与信枠クリア日になるタイミングで、与信枠がクリアされる。与信枠がクリアされると、与信枠クリア日に、クレジットカードの利用可能額が増加する。与信枠クリア日は、例えば、クレジットカード会社ごとに定められている。例えば、与信枠クリア日は、月初の日である。また例えば、与信枠クリア日は、引き落とし日である。引き落とし日は、ユーザの口座からクレジットカードの利用料金が引き落とされる日である。また、与信枠クリア日ではなくとも、与信枠が解除される場合もある。例えば、確保されていた与信枠に対応する取り引きが取り消された場合である。クレジットカードの利用可能額が宿泊料金以上となっているときに宿泊施設予約サーバ1が再与信確認を行えば、与信を確認することができる。従って、宿泊施設予約サーバ1は、オンラインカード決済を行うことができる。ユーザにとっては、利用可能額が増加することを待って再度オンラインカード決済を指定して予約を要求するという作業をユーザが行わなくてもよいという利点がある。
宿泊施設予約サーバ1は、チェックイン日までの日数が与信期間の日数以下になった日から、チェックイン日の前日までの何れかの日に、再与信確認を行ってもよい。このタイミングで再与信確認が行われることで、宿泊料金の決済の安全性を高めることができるからである。その理由は、ユーザが指定したクレジットカードでの与信が確認されている状態でチェックイン日にユーザが宿泊施設の利用を開始するからである。例えば、ユーザが宿泊施設を利用している期間中にクレジットカードでの支払い能力がなくなった場合、宿泊施設の提供者が、宿泊施設に滞在しているユーザに直接決済を求めればよい。また、ユーザが予約をキャンセルする場合や、ユーザが何の連絡もなくチェックイン日になっても宿泊施設に現れない場合がある。この場合は、例えば、宿泊施設予約サーバ1が、宿泊施設の提供者からの要求に基づき、確保されている与信枠内で与信期間内にキャンセル料金を決済すればよい。
宿泊施設予約サーバ1は、決済日までの日数が与信期間の日数以下になった日以降の何れかの日に、再与信確認を行ってもよい。このタイミングで再与信確認が行われることで、宿泊料金の決済の安全性を更に高めることができるからである。その理由は、再与信確認により与信を確認することができた場合には、このときに確保された与信枠に基づいて、宿泊施設予約サーバ1が決済日に宿泊料金を決済することができるからである。
宿泊施設予約サーバ1は、与信枠クリア日に、再与信確認を行ってもよい。このタイミングで再与信確認が行われることで、与信を確認することができる蓋然性を高めることができるからである。
なお、本実施形態においては、宿泊施設予約サーバ1は、決済日までの日数が与信期間の日数以下になった日以降の日のうち、与信枠クリア日に再与信確認を行う。決済日までの日数が与信期間の日数以下になった日から、チェックイン日の前日までに与信枠クリア日がなかった場合、宿泊施設予約サーバ1は、別の日に再与信確認を行ってもよいし、オンラインカード決済による予約を受け付けなくてもよい。
以下に、予約から決済までの処理の概要を説明する。図2は、予約から決済までの処理の流れを示す図である。なお、図2は、与信期間の日数が30日である場合の例を示す。また、図2は、与信を確認することができた場合を、「OK」で示し、与信を確認することができなかった場合を、「NG」で示している。
図2に示すように、ユーザは、オンラインカード決済を指定して、予約の操作を行う。すると、宿泊施設予約サーバ1は、指定されたクレジットカードの与信確認を行う(図2(1))。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法をオンラインカード決済として予約を受け付ける。そして、ユーザが宿泊施設に宿泊した後、宿泊施設予約サーバ1は、チェックアウト日の翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する(図2(2))。
一方、宿泊施設予約サーバ1は、与信を確認することができなかった場合にも、予約を受け付ける。その後、決済日の30日前となった日以降の与信枠クリア日に、宿泊施設予約サーバ1は、予約時に指定されたクレジットカードの再与信確認を行う(図2(3))。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法をオンラインカード決済とする。そして、宿泊施設予約サーバ1は、チェックアウト日の翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する(図2(4))。
一方、宿泊施設予約サーバ1は、再与信確認において与信を確認することができなかった場合、決済方法を現金決済とする。その後、ユーザが宿泊施設に宿泊してチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する(図2(5))。
図2(1)において、予約時に与信を確認することができなかった場合、宿泊施設予約サーバ1は、実際には、予約を受け付ける前に、予約を要求したユーザのユーザ端末4へ決済方法変更ページを送信する。決済方法変更ページは、決済方法を変更するためのWebページである。
図3は、決済方法変更ページの画面表示例を示す図である。図3に示すように、ラジオボタン110、120、130、140、第2希望カード指定領域150、及び決定ボタン160を含む。ラジオボタン110は、オンラインカード決済を決済方法として選択するためのラジオボタンである。ラジオボタン120は、現地決済を決済方法として選択するためのラジオボタンである。ラジオボタン130は、最初に指定されたクレジットカードのみをオンラインカード決済に利用することを選択するためのラジオボタンである。ラジオボタン140は、最初に指定されたクレジットカード以外のクレジットカードを、第2希望のクレジットカードとしてオンラインカード決済に利用してもよいことを選択するためのラジオボタンである。ここで、予約時に最初に指定されたクレジットカードを、「第1希望のクレジットカード」という。ユーザがラジオボタン110及び120のうちラジオボタン110を選択した場合にのみ、ユーザは、ラジオボタン130及び140のうち何れかを選択することができる。第2希望カード指定領域150は、第2希望のクレジットカードを指定するための情報である。ユーザがラジオボタン130及び140のうちラジオボタン140を選択した場合にのみ、ユーザは、第2希望カード指定領域150において第2希望のクレジットカードを指定することができる。第2希望カード指定領域150において、ユーザは、第2希望のクレジットカードとして、宿泊施設予約サイトに予め登録しておいたクレジットカードと、別のクレジットカードのうち何れかを選択することができる。第2希望のクレジットカードとして別のクレジットカードをユーザが選択した場合、第2希望カード指定領域150において、ユーザは、第2希望のクレジットカードの情報を入力することができる。入力可能な情報としては、クレジットカード会社、カード番号、有効期限、名義人の名称等がある。決定ボタン160は、決済方法の変更内容を確定するためのボタンである。
ユーザは、決済方法をオンラインカード決済から変更せず、且つ、予約時に指定したクレジットカードのみをオンラインカード決済に利用する場合には、ラジオボタン110及び130を選択する。また、ユーザは、決済方法はオンラインカード決済から変更しないが、第2希望のクレジットカードをオンラインカード決済に利用してもよい場合には、ラジオボタン110及び140を選択し、第2希望カード指定領域150において、第2希望のクレジットカードを指定する。一方、ユーザは、決済方法を現地決済に変更する場合には、ラジオボタン120を選択する。
決済方法をオンラインカード決済から変更せず、且つ、予約時に指定したクレジットカードのみをオンラインカード決済に利用することをユーザが選択した場合、図2(1)において、宿泊施設予約サーバ1は、決済方法はオンラインカード決済であるとして、予約を受け付ける。その後、宿泊施設予約サーバ1は、図2(3)において、第1希望のクレジットカードの与信を確認する。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法を変更しない。そして、宿泊施設予約サーバ1は、第1希望のクレジットカードによるオンラインカード決済とすることを示す情報を出力する。この情報として、宿泊施設予約サーバ1は、例えば、オンラインカード決済通知メールを、予約したユーザ宛てに送信する。オンラインカード決済通知メールは、決済方法が、第1希望のクレジットカードによるオンラインカード決済から変更されないことを通知する電子メールである。その後、宿泊施設予約サーバ1は、第1希望のクレジットカードで宿泊料金を決済する(図2(4))。
再与信確認において与信を確認することができなかった場合、宿泊施設予約サーバ1は、決済方法をオンラインカード決済から現地決済に変更する。そして、宿泊施設予約サーバ1は、決済方法をオンラインカード決済とは異なる方法にすることを示す情報を出力する。この情報として、宿泊施設予約サーバ1は、例えば、現地決済通知メールを、予約したユーザ宛てに送信する。現地決済通知メールは、決済方法がオンラインカード決済から現地決済に変更されたことを通知する電子メールである。なお、ユーザ端末4により現地決済通知メールを受信したユーザは、例えば、予約時に指定したクレジットカードとは異なるクレジットカードを指定して、決済方法をオンラインカード決済に変更することができる。
決済方法はオンラインカード決済から変更しないが、第2希望のクレジットカードをオンラインカード決済に利用してもよいとユーザが選択した場合、図2(1)において、宿泊施設予約サーバ1は、第2希望のクレジットカードの与信を確認する。このとき、宿泊施設予約サーバ1は、与信を確認することができなかった場合には、予約を受け付けず、決済方法変更ページを再度送信する。一方、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法はオンラインカード決済であるとして、予約を受け付ける。その後、宿泊施設予約サーバ1は、図2(3)において、第1希望のクレジットカードの与信を確認し、与信を確認することができた場合には、オンラインカード決済通知メールを送信する。その後、宿泊施設予約サーバ1は、第1希望のクレジットカードで宿泊料金を決済する(図2(4))。
第1希望のクレジットカードの与信を確認することができなかった場合、宿泊施設予約サーバ1は、第2希望のクレジットカードの与信を確認する。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法を変更しない。その後、宿泊施設予約サーバ1は、第2希望のクレジットカードで宿泊料金を決済する(図2(4))。一方、宿泊施設予約サーバ1は、与信を確認することができなかった場合には、決済方法を現地決済に変更し、現地決済通知メールを送信する。
決済方法を現地決済に変更することをユーザが選択した場合、図2(1)において、宿泊施設予約サーバ1は、決済方法は現地決済であるとして、予約を受け付ける。その後、宿泊施設予約サーバ1は、図2(3)において、第1希望のクレジットカードの与信を確認する。このとき、宿泊施設予約サーバ1は、与信を確認することができなかった場合には、決済方法を変更しない。一方、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法を変更しないが、第1希望のクレジットカードによるオンラインカード決済とすることを示す情報を出力する。この情報として、宿泊施設予約サーバ1は、例えば、決済方法復帰可能通知メールを送信する。決済方法復帰可能通知メールは、決済方法を、現地決済から第1希望のクレジットカードによるオンラインカード決済に戻すことが可能であることを通知する電子メールである。この時点で宿泊施設予約サーバ1が決済方法を変更しない理由は、ユーザの最新の選択内容を尊重するためである。
決済方法復帰可能通知メールには、例えば、決済方法を戻すためのURLが記載されている。ユーザがURLを選択すると、ユーザ端末4は宿泊施設予約サーバ1へリクエストを送信し、宿泊施設予約サーバ1は、決済方法復帰承認ページをユーザ端末4へ送信する。決済方法復帰承認ページは、決済方法を戻すことを承認するためのWebページである。決済方法復帰承認ページにおいて、決済方法を戻すことを承認するボタンをユーザが選択すると、宿泊施設予約サーバ1は、決済方法を、現地決済から第1希望のクレジットカードによるオンラインカード決済に戻す。宿泊施設予約サーバ1は、決済方法をオンラインカード決済に戻すことができる期間を制限してもよい。例えば、宿泊施設予約サーバ1は、決済方法をオンラインカード決済に戻すことができる期間を、チェックイン日の前日までとしてもよい。
なお、宿泊施設予約サーバ1は、チェックイン日の前日に、宿泊施設を予約したユーザ宛てに予約内容を記載した電子メールを送信する。そのため、宿泊施設予約サーバ1は、オンラインカード決済通知メールや現地決済通知メールを送信する代わりに、予約内容を記載する電子メールに、確定した決済方法を記載してもよい。
また、宿泊施設予約サーバ1は、予約時に第1希望のクレジットカードの与信を確認することができなかった場合には、決済方法変更ページを送信しなくてもよい。この場合、宿泊施設予約サーバ1は、決済方法をオンラインカード決済から変更せず、且つ、予約時に指定したクレジットカードのみをオンラインカード決済に利用することをユーザが選択した場合と同様の処理を行う。
ところで、予約時にユーザが指定したチェックイン日及びチェックアウト日によっては、宿泊施設の利用日数が、与信期間の日数以上となる場合がある。宿泊施設の利用日数は、宿泊日数よりも1日多い日数である。この場合において、決済日から与信期間日数前の日以降に再与信確認を行うと仮定した場合、宿泊施設予約サーバ1はチェックイン日以降に再与信確認を行うことになる。しかしながら、上述した宿泊料金の決済の安全性の観点から、宿泊施設予約サーバ1は、チェックイン日の前日までに再与信確認を行う。この場合、再与信確認によって確保された与信枠は、決済日より前に消滅する。すると、決済日にクレジットカードで宿泊料金を決済することができない場合がある。そこで、宿泊施設予約サーバ1は、決済日から与信期間日数前の日以降に、更に与信を確認する。3回目の与信確認を、「再々与信確認」という。
本実施形態においては、宿泊施設予約サーバ1は、チェックイン日までの日数が与信期間の日数以下になった日から、チェックイン日の前日までのうち、与信枠クリア日に再与信確認を行う。チェックイン日までの日数が与信期間の日数以下になった日から、チェックイン日の前日までに与信枠クリア日がなかった場合、宿泊施設予約サーバ1は、別の日に再与信確認を行ってもよいし、オンラインカード決済による予約を受け付けなくてもよい。再与信確認は、チェックイン日の前日までに行われればよい。また、宿泊施設予約サーバ1は、決済日までの日数が与信期間の日数以下になった日に、再々与信確認を行う。なお、再々与信確認は、決済日までの日数が与信期間の日数以下になった日以降に行われればよい。
以下に、概要を説明する。図4は、宿泊施設の利用日数が与信期間の日数以上である場合の予約から決済までの処理の流れを示す図である。なお、図4は、与信期間の日数が30日である場合の例を示す。
図4に示すように、ユーザが、チェックイン日及びチェックアウト日を指定する。その結果、利用日数が30日以上であるとする。また、ユーザは、オンラインカード決済を指定して、予約の操作を行う。宿泊施設予約サーバ1は、図2(1)と同様に、与信確認を行い(図4(1))、与信を確認することができなかった場合でも、予約を受け付ける。
その後、チェックイン日の30前からチェックイン日の前日までの間の与信枠クリア日に、宿泊施設予約サーバ1は、予約時に指定されたクレジットカードの再与信確認を行う(図4(2))。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法をオンラインカード決済とする。
その後、チェックイン日以降、決済日の30日前となった日に、宿泊施設予約サーバ1は、予約時に指定されたクレジットカードの再々与信確認を行う(図4(3))。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、決済方法を変更しない。そして、宿泊施設予約サーバ1は、チェックアウトの翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する(図4(4))。一方、宿泊施設予約サーバ1は、与信を確認することができなかった場合には、決済方法を現地決済に変更する。その後、ユーザがチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する(図4(5))。
ユーザが実際に宿泊施設を利用した際、予約時に確定した宿泊料金とは別に、料金が発生する場合がある。例えば、利用料金が予約時の宿泊料金に含まれていないサービスをユーザが利用した場合や、宿泊施設で何らかの物をユーザが購入した場合である。宿泊施設の利用によって宿泊料金とは別に発生する料金を、「オプション料金」という。ユーザは、オンラインカード決済を利用する場合、オプション料金と宿泊料金を含む利用料金をオンラインカード決済で決済することができる。具体的には、例えば、チェックアウトの際に、宿泊施設の提供者がオプション料金を精算する。そして、提供者は、宿泊施設端末3を操作して、オプション料金の登録を要求する。すると、宿泊施設予約サーバ1は、オプション料金について与信確認を行う。このとき、宿泊施設予約サーバ1は、与信を確認することができた場合には、チェックアウト日の翌日に、オプション料金を含めて宿泊料金を決済する。一方、宿泊施設予約サーバ1が与信を確認することができなかった場合には、例えば、その場でユーザがオプション料金の決済の手続を行う。この場合でも、宿泊料金は、オンラインカード決済で決済される。
[3.宿泊施設予約サーバの構成]
次に、宿泊施設予約サーバ1の構成について、図5及び図6を用いて説明する。
図5は、本実施形態に係る宿泊施設予約サーバ1の概要構成の一例を示すブロック図である。図5に示すように、宿泊施設予約サーバ1は、通信部11と、記憶部12と、入出力インターフェース13と、システム制御部14と、を備えている。そして、システム制御部14と入出力インターフェース13とは、システムバス15を介して接続されている。
通信部11は、ネットワークNWに接続して、ユーザ端末4等との通信状態を制御するようになっている。
記憶部12は、例えば、ハードディスクドライブ等により構成されている。この記憶部12には、会員情報DB12a、宿泊施設情報DB12b、予約情報DB12c等のデータベースが構築されている。「DB」は、データベースの略語である。なお、記憶部12は、本発明における記憶手段の一例である。
図6(a)は、会員情報DB12aに登録される内容の一例を示す図である。会員情報DB12aには、情報処理システムSに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報DB12aには、ユーザID、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス、登録クレジットカード情報等が、ユーザごとに対応付けて登録される。ユーザIDは、ユーザの識別情報である。登録クレジットカード情報は、ユーザにより登録されたクレジットカードのカード情報である。登録クレジットカード情報には、例えば、クレジットカード会社、カード番号、有効期限、名義人の名称等の情報が設定される。ユーザは、予めカード情報を登録しておくことにより、予約のたびにカード情報を入力しなくてもよい。
図6(b)は、宿泊施設情報DB12bに登録される内容の一例を示す図である。宿泊施設情報DB12bには、宿泊施設に関する宿泊施設情報が登録される。具体的に、宿泊施設情報DB12bには、施設ID、宿泊施設名、郵便番号、住所、電話番号、FAX番号、電子メールアドレス、プラン情報等の宿泊施設の属性が、宿泊施設ごとに対応付けて登録される。施設IDは、宿泊施設の識別情報である。プラン情報は、宿泊施設が提供する宿泊プランに関する情報である。宿泊プランは、例えば、宿泊施設の提供者により企画された宿泊サービスである。プラン情報には、例えば、プランID、宿泊プラン名、客室タイプID、宿泊プランの内容、1泊の宿泊料金の説明等の宿泊プランの属性が宿泊プランごとに設定されている。プランIDは、宿泊プランの識別情報である。客室タイプIDは、客室のタイプを示す識別情報である。
図6(c)は、予約情報DB12cに登録される内容の一例を示す図である。予約情報DB12cには、受け付けられた予約に関する予約情報が登録される。具体的に、予約情報DB12cには、予約番号、予約日、ユーザID、施設ID、プランID、客室タイプ、チェックイン日、チェックアウト日、利用人数、宿泊料金、決済方法情報、オンラインカード決済管理情報等の情報が予約ごとに対応付けて登録される。予約番号は、予約の識別情報である。ユーザIDは、予約したユーザを示す。施設IDは、予約された宿泊施設を示す。プランID及び客室タイプIDは、予約された宿泊プラン及び客室タイプを示す。宿泊料金は、予約時に確定している利用料金である。宿泊料金は、宿泊プラン、客室タイプ、宿泊日数及び利用人数に応じて決定される。決済方法情報は、決済方法を示す情報である。決済方法情報には、「現地決済」または「オンラインカード決済」の何れかが設定される。
オンラインカード決済管理情報は、オンラインカード決済に関する情報である。オンラインカード決済管理情報には、第1クレジットカード情報、第2クレジットカード情報、利用カード種別、与信確認結果、宿泊料金承認番号、オプション料金決済フラグ、オプション料金、オプション料金承認番号、再与信確認フラグ、再与信確認日、再々与信確認フラグ及び再々与信確認日が設定される。第1クレジットカード情報は、ユーザにより指定された第1希望のクレジットカードのカード情報である。第2クレジットカード情報は、ユーザにより指定された第2希望のクレジットカードのカード情報である。利用カード種別は、オンラインカード決済に利用されるクレジットカードの種類を示す情報である。利用カード種別には、「第1カード」または「第2カード」の何れかが設定される。「第1カード」は、第1希望のクレジットカードが利用されることを示す。「第2カード」は、第2希望のクレジットカードが利用されることを示す。与信確認結果は、最新の与信確認における確認結果を示す。与信確認結果にOKが設定されている場合、与信を確認することができたことを示す。与信確認結果にNGが設定されている場合、与信を確認することができなかったことを示す。宿泊料金承認番号は、宿泊料金の決済についてクレジットカードの与信が承認された場合に、決済サーバ2から宿泊施設予約サーバ1に送信される承認番号である。承認番号は、与信が承認された取り引きの識別情報である。オプション料金決済フラグは、オプション料金をオンラインカード決済で決済するか否かを示す情報である。オプション料金決済フラグがONに設定されている場合、オプション料金はオンラインカード決済で決済されることを示す。オプション料金決済フラグがOFFに設定されている場合、オプション料金はオンラインカード決済では決済されないことを示す。オプション料金承認番号は、オプション料金の決済についてクレジットカードの与信が承認された場合に、決済サーバ2から宿泊施設予約サーバ1に送信される承認番号である。再与信確認フラグは、再与信確認が必要であるか否かを示す情報である。再与信確認フラグがONに設定されている場合、再与信確認が必要であることを示す。再与信確認フラグがOFFに設定されている場合、再与信確認が不要であることを示す。再与信確認日は、再与信確認が行われる日を示す。再々与信確認フラグは、再々与信確認が必要であるか否かを示す情報である。再々与信確認フラグがONに設定されている場合、再々与信確認が必要であることを示す。再々与信確認フラグがOFFに設定されている場合、再々与信確認が不要であることを示す。再々与信確認日は、再々与信確認が行われる日を示す。
次に、記憶部12に記憶されるその他の情報について説明する。記憶部12には、Webページを表示するためのHTML(HyperText Markup Language)文書、XML(Extensible Markup Language)文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。
また、記憶部12には、オペレーティングシステム、WWW(World Wide Web)サーバプログラム、DBMS(Database Management System)、宿泊施設予約処理プログラム等の各種プログラムが記憶されている。宿泊施設予約処理プログラムは、宿泊施設の検索、宿泊施設の予約、宿泊料金の与信確認や決済の処理を実行するためのプログラムである。宿泊施設予約処理プログラムは、本発明における情報処理プログラムの一例である。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしてもよいし、DVD(Digital Versatile Disc)等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
入出力インターフェース13は、通信部11及び記憶部12とシステム制御部14との間のインターフェース処理を行うようになっている。
システム制御部14は、CPU14a、ROM(Read Only Memory)14b、RAM(Random Access Memory)14c等により構成されている。そして、システム制御部14は、CPU14aが、各種プログラムを読み出し実行することにより、本発明における予約手段、確認手段、出力手段、第2確認手段、決済手段及び判定手段として機能するようになっている。
なお、宿泊施設予約サーバ1が、複数のサーバ装置で構成されてもよい。例えば、宿泊施設の検索を行うサーバ装置、宿泊施設の予約や与信確認の処理を行うサーバ装置、ユーザ端末4からのリクエストに応じてWebページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されてもよい。
[4.情報処理システムの動作]
次に、情報処理システムSの動作について、図7乃至図12を用いて説明する。
図7は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14の予約処理における処理例を示すフローチャートである。
例えば、ユーザが宿泊施設サイトにおいて宿泊施設を検索し、所望の宿泊施設、宿泊プラン及び客室タイプを選択する。次いで、ユーザは、チェックイン日、チェックアウト日及び利用人数を選択する。すると、ユーザ端末4の画面には、決済方法指定ページが表示される。決済方法指定ページは、決済方法を指定するためのWebページである。ここで、ユーザは、決済方法としてオンラインカード決済を選択した場合、決済に利用するクレジットカードのカード情報を入力する。このとき、ユーザは、会員情報に情報が登録されているクレジットカードを指定することができる。この場合、ユーザは、カード情報を入力しない。ユーザは、必要な選択及び入力を行った後、予約を要求するためのボタンを選択する。すると、ユーザ端末4は、予約リクエストを宿泊施設予約サーバ1へ送信する。予約リクエストは、ユーザID、ユーザにより選択された宿泊施設、宿泊プラン及び客室タイプに対応する施設ID、プランID及び客室IDと、チェックイン日、チェックアウト日及び利用人数とを含む。また、予約リクエストは、会員情報に情報が登録されているクレジットカードを利用するか否かを示す情報と、ユーザにより入力されたカード情報とを含む。予約処理は、宿泊施設予約サーバ1が予約リクエストを受信したときに開始される。
図7に示すように、システム制御部14は、ユーザにより選択された決済方法がオンラインカード決済であるか否かを判定する(ステップS1)。このとき、システム制御部14は、決済方法がオンラインカード決済ではないと判定した場合には(ステップS1:NO)、決済方法情報に「現地決済」を設定する。また、システム制御部14は、再与信確認フラグ及び再々与信確認フラグをOFFに設定する(ステップS2)。次いで、システム制御部14は、予約情報を登録する(ステップS3)。具体的に、システム制御部14は、新しい予約番号を生成する。次いで、システム制御部14は、予約番号、予約リクエストに含まれる情報、設定を行った決済方法情報、再与信確認フラグ及び再々与信確認フラグ等を含む予約情報を生成する。次いで、システム制御部14は、生成した予約情報を予約情報DB12cに登録する。システム制御部14は、ステップS3の処理を終えると、予約処理を終了させる。
一方、システム制御部14は、決済方法がオンラインカード決済であると判定した場合には(ステップS1:YES)、ユーザにより指定されたクレジットカードのカード情報に基づいて、与信を確認する(ステップS4)。具体的に、システム制御部14は、予約リクエストに含まれる施設ID、プランID、客室タイプID及び利用人数に基づいて、宿泊料金を計算する。また、システム制御部14は、ユーザが指定したクレジットカードのカード情報を取得する。ユーザがカード情報を入力した場合には、予約情報リクエストからカード情報を取得する。一方、システム制御部14は、ユーザが、登録されているクレジットカードを指定した場合には、会員情報DB12aから、予約を要求したユーザのユーザIDに対応する会員情報を検索する。そして、システム制御部14は、検索した会員情報から登録クレジットカード情報を取得する。システム制御部14は、カード情報を取得すると、与信確認リクエストを決済サーバ2に送信する。与信確認リクエストは、取得されたカード情報、利用額等を含む。システム制御部14は、利用額として宿泊料金を設定する。
決済サーバ2は、与信確認リクエストを受信すると、与信を承認するか否かを判定する。具体的に、決済サーバ2は、与信確認リクエストに含まれるカード情報が、有効なクレジットカードのカード情報であるか否かを判定する。また、決済サーバ2は、カード情報に基づいて、クレジットカードの有効期限が切れているか否かを判定する。また、決済サーバ2は、現時点でのクレジットカードの利用可能額が、与信確認リクエストに含まれる利用額以上であるか否かを判定する。
決済サーバ2は、カード情報が有効なクレジットカードのカード情報であり、有効期限が切れておらず、且つ、利用可能額が利用額以上である場合、与信を承認する。この場合、決済サーバ2は、新たな承認番号を発行する。また、決済サーバ2は、宿泊料金に相当する与信枠を確保する。例えば、決済サーバ2は、承認番号、宿泊料金、カード情報等を対応付けて、決済サーバ2が備えるデータベースに登録する。また、決済サーバ2は、カード情報に対応する利用可能額を更新する。そして、決済サーバ2は、承認番号を含む与信確認応答を宿泊施設予約サーバ1に送信する。
一方、決済サーバ2は、カード情報が有効なクレジットカードのカード情報ではない場合、有効期限が切れている場合、または、利用可能額が利用額未満である場合、与信を承認しない。この場合、決済サーバ2は、エラー種別を含む与信確認応答を宿泊施設予約サーバ1に送信する。この場合、与信確認応答は承認番号を含まない。エラー種別は、与信を承認することができない理由を示す情報である。エラー種別としては、例えば、「カード無効」、「期限切れ」、「限度額オーバー」等がある。「カード無効」は、カード情報が無効であることを示す。「期限切れ」は、クレジットカードの有効期限が切れていることを示す。「限度額オーバー」は、利用額が利用可能額を超えていることを示す。
システム制御部14は、決済サーバ2から与信確認応答を受信すると、与信を確認することができたか否かを判定する(ステップS5)。このとき、システム制御部14は、決済サーバ2からから承認番号を含む与信確認応答を受信した場合には、与信を確認することができたと判定する(ステップS5:YES)。この場合、システム制御部14は、オンラインカード決済管理情報の設定を行う(ステップS6)。具体的に、システム制御部14は、決済方法情報に「オンラインカード決済」を設定する。また、システム制御部14は、第1クレジットカード情報に、ステップS4で取得したカード情報を設定する。また、システム制御部14は、利用カード種別に「第1カード」を設定する。また、システム制御部14は、与信確認結果にOKを設定する。また、システム制御部14は、宿泊料金承認番号に、与信確認応答に含まれる承認番号を設定する。また、システム制御部14は、オプション料金決済フラグをOFFに設定する。また、システム制御部14は、再与信確認フラグ及び再々与信確認フラグをOFFに設定する。
次いで、システム制御部14は、ユーザにより指定されたクレジットカードのカード情報を含む予約情報を登録する(ステップS7)。具体的に、システム制御部14は、新しい予約番号、予約リクエストに含まれる情報、設定を行ったオンラインカード決済管理情報を含む予約情報を生成する。次いで、システム制御部14は、生成した予約情報を予約情報DB12cに登録する。システム制御部14は、ステップS7の処理を終えると、予約処理を終了させる。
一方、システム制御部14は、承認番号を含まない与信確認応答を受信した場合には、与信を確認することができなかったと判定する(ステップS5:NO)。この場合、システム制御部14は、決済サーバ2から受信した与信確認応答に含まれるエラー種別を取得する。そして、システム制御部14は、判定手段として、エラー種別が「限度額オーバー」であるか否かを判定する(ステップS8)。このとき、システム制御部14は、エラー種別が「限度額オーバー」ではないと判定した場合には(ステップS8:NO)、決済方法指定ページを、予約リクエストの送信元のユーザ端末4へ送信する(ステップS9)。システム制御部14は、ステップS9の処理を終えると、予約処理を終了させる。決済方法指定ページにおいて、ユーザは、決済方法を再度指定する。そして、ユーザが、予約を要求するためのボタンを選択すると、ユーザ端末4は、予約リクエストを宿泊施設予約サーバ1へ送信する。
一方、システム制御部14は、エラー種別が「限度額オーバー」であると判定した場合には(ステップS8:YES)、明日から予約リクエストに含まれるチェックイン日の前日までに与信枠クリア日が存在するか否かを判定する(ステップS10)。なお、クレジットカード会社ごとに与信枠クリア日が異なる場合がある。この場合、システム制御部14は、ステップS4で取得したカード情報に含まれるクレジットカード会社の情報に基づいて、与信枠クリア日を特定する。システム制御部14は、与信枠クリア日が存在しないと判定した場合には(ステップS10:NO)、ステップS9に移行する。つまり、システム制御部14は、与信枠クリア日が存在しない場合には、第1希望のクレジットカードを利用するオンラインカード決済による予約を受け付けない。
一方、システム制御部14は、与信枠クリア日が存在すると判定した場合には(ステップS10:YES)、決済方法変更ページを、予約リクエストの送信元のユーザ端末4へ送信する(ステップS11)。次いで、システム制御部14は、予約リクエストに含まれる情報と、ステップS4において取得したカード情報とを、予約を要求したユーザのユーザIDに対応付けて、記憶部12に一時的に記憶させる。システム制御部14は、この処理を終えると、予約処理を終了させる。
図8は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14の決済方法変更予約処理における処理例を示すフローチャートである。
ユーザ端末4は、宿泊施設予約サーバ1から受信した決済方法変更ページを表示する。ここで、ユーザは、決済方法、及び第2希望のクレジットカードを指定するか否かの選択を行う。また、ユーザは、必要に応じて第2希望のクレジットカードのカード情報を入力する。そして、ユーザ端末4は、決定ボタン160を選択する。すると、ユーザ端末4は、決済方法変更予約リクエストを宿泊施設予約サーバ1に送信する。決済方法変更予約リクエストは、ユーザID、ユーザにより選択された決済方法、及び第2希望のクレジットカードを指定するか否かを示す情報を含む。また、決済方法変更予約リクエストは、会員情報に情報が登録されているクレジットカードを利用するか否かを示す情報と、ユーザにより入力されたカード情報とを含む。決済方法変更予約処理は、宿泊施設予約サーバ1が決済方法変更予約リクエストを受信したときに開始される。
図8に示すように、システム制御部14は、ユーザにより選択された決済方法がオンラインカード決済であるか否かを判定する(ステップS21)。このとき、システム制御部14は、決済方法がオンラインカード決済ではないと判定した場合には(ステップS21:NO)、決済方法情報を「現地決済」に変更する(ステップS22)。次いで、システム制御部14は、ステップS29に移行する。
一方、システム制御部14は、決済方法がオンラインカード決済であると判定した場合には(ステップS21:YES)、第2希望のクレジットカードが指定されたか否かを判定する(ステップS23)。このとき、システム制御部14は、第2希望のクレジットカードが指定されていないと判定した場合には(ステップS23:NO)、ステップS28に移行する。一方、システム制御部14は、第2希望のクレジットカードが指定されたと判定した場合には(ステップS23:YES)。第2希望のクレジットカードのカード情報に基づいて、与信を確認する(ステップS24)。この処理の内容は、図7に示す予約処理のステップS4の処理内容と基本的に同様である。ただし、システム制御部14は、決済方法変更リクエストに基づいて第2希望のクレジットカードのカード情報を取得する。そして、システム制御部14は、取得したカード情報を与信確認リクエストに設定する。
次いで、システム制御部14は、第2希望のクレジットカードの与信を確認することができたか否かを判定する(ステップS25)。このとき、システム制御部14は、与信を確認することができなかったと判定した場合には(ステップS25:NO)、決済方法指定ページを、予約リクエストの送信元のユーザ端末4へ送信する(ステップS26)。システム制御部14は、ステップS26の処理を終えると、決済方法変更予約処理を終了させる。一方、システム制御部14は、与信を確認することができたと判定した場合には(ステップS25:YES)、第2クレジットカード情報に、ステップS24で取得したカード情報を設定する。また、システム制御部14は、宿泊料金承認番号に、ステップS24において受信した与信確認応答に含まれる承認番号を設定する(ステップS27)。次いで、システム制御部14は、ステップS28に移行する。
ステップS28において、システム制御部14は、決済方法情報に「オンラインカード決済」を設定する。次いで、システム制御部14は、オンラインカード決済管理情報の主要な設定を行う(ステップS29)。具体的に、システム制御部14は、第1クレジットカード情報に、予約を要求したユーザIDに対応付けて記憶部12に記憶しておいたカード情報を設定する。また、システム制御部14は、利用カード種別に「第1カード」を設定する。また、システム制御部14は、与信確認結果にNGを設定する。また、システム制御部14は、オプション料金決済フラグをOFFに設定する。また、システム制御部14は、再与信確認フラグをONに設定する。また、システム制御部14は、再与信確認日に、明日からチェックイン日の前日までの間に存在する与信枠クリア日を設定する。このとき、システム制御部14は、与信枠クリア日が複数存在する場合には、例えば、チェックイン日に最も近い与信枠クリア日を、再与信確認日として設定してもよい。その理由は、再与信確認において確保された与信枠に基づいて決済を行うことができるようにするためである。
次いで、システム制御部14は、予約を要求したユーザIDに対応付けて記憶部12に記憶しておいたチェックイン日及びチェックアウト日に基づいて、宿泊施設の利用日数を計算する。そして、システム制御部14は、利用日数が与信日数未満であるか否かを判定する(ステップS30)。このとき、システム制御部14は、利用日数が与信日数未満であると判定した場合には(ステップS30:YES)、再々与信確認フラグをOFFに設定する(ステップS31)。次いで、システム制御部14は、ステップS33に移行する。
一方、システム制御部14は、利用日数が与信日数以上であると判定した場合には(ステップS30:NO)、再々与信確認フラグをONに設定する。また、システム制御部14は、チェックアウト日の翌日を、決済日として設定する。そして、システム制御部14は、再々与信確認日に、決済日から与信日数前の日を設定する(ステップS32)。次いで、システム制御部14は、ステップS33に移行する。
ステップS33において、システム制御部14は、予約手段として、ユーザにより指定されたクレジットカードのカード情報を含む予約情報を登録する。具体的に、システム制御部14は、新しい予約番号、予約を要求したユーザIDに対応付けて記憶部12に記憶しておいた情報、設定を行った決済方法情報、第1クレジットカード情報、第2クレジットカード情報、利用カード種別、与信確認結果、宿泊料金承認番号、オプション料金決済フラグ、再与信確認フラグ、再与信確認日、再々与信確認フラグ及び再々与信確認日等を含む予約情報を生成する。次いで、システム制御部14は、生成した予約情報を予約情報DB12cに登録する。システム制御部14は、予約情報を登録することにより、要求された予約を受け付ける。システム制御部14は、ステップS33の処理を終えると、予約処理を終了させる。
図9は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14の再与信確認処理における処理例を示すフローチャートである。宿泊施設予約サーバ1は、再与信確認処理と、後述する再々与信確認処理及び決済処理とを、1日に1回実行する。宿泊施設予約サーバ1は、再与信確認処理、再々与信確認処理及び決済処理を連続して実行してもよい。
図9に示すように、システム制御部14は、予約情報DB12cから、再与信確認フラグがONに設定されている予約情報のうち、再与信確認日が今日である予約情報を検索する(ステップS41)。次いで、システム制御部14は、検索した予約情報のうち1つを選択する(ステップS42)。次いで、システム制御部14は、選択した予約情報に、第2クレジットカード情報が設定されているか否かを判定する(ステップS43)。このとき、システム制御部14は、第2クレジットカード情報が設定されていないと判定した場合には(ステップS43:NO)、ステップS45に移行する。一方、システム制御部14は、第2クレジットカード情報が設定されていると判定した場合には(ステップS43:YES)、選択した予約情報が対応する予約について、予約時の与信確認により確保された第2希望のクレジットカードの与信を取り消す(ステップS44)。この処理を行う理由は、1つの予約に対して与信枠が複数確保されることを防止するためである。具体的に、システム制御部14は、選択した予約情報から宿泊料金承認番号を取得する。次いで、システム制御部14は、取得した宿泊料金承認番号を承認番号として含む与信取消リクエストを決済サーバ2に送信する。決済サーバ2は、与信取消リクエストを受信すると、与信取消リクエストに含まれる承認番号に対応する与信枠を解除する。なお、システム制御部14は、前回与信確認を行った日から与信期間が経過している場合には、与信の取り消しを実行しなくてもよい。システム制御部14は、ステップS45の処理を終えると、ステップS45に移行する。
ステップS45において、システム制御部14は、確認手段として、選択した予約情報に含まれる第1クレジットカード情報に基づいて、第1希望のクレジットカードの与信を確認する。この処理の内容は、図7に示す予約処理のステップS4の処理内容と基本的に同様である。ただし、システム制御部14は、選択した予約情報に含まれる第1クレジットカード情報を、与信確認リクエストに設定する。
次いで、システム制御部14は、与信を確認することができたか否かを判定する(ステップS46)。このとき、システム制御部14は、与信を確認することができなかったと判定した場合には(ステップS46:NO)、ステップS51に移行する。一方、システム制御部14は、与信を確認することができたと判定した場合には(ステップS46:YES)、ステップS45において決済サーバ2から受信した与信確認応答に含まれる承認番号で、選択した予約情報に含まれる宿泊料金承認番号を上書きする。次いで、システム制御部14は、選択した予約情報に含まれる与信確認結果にOKを設定する(ステップS47)。
次いで、システム制御部14は、選択した予約情報に含まれる決済方法情報が「オンラインカード決済」であるか否かを判定する(ステップS48)。このとき、システム制御部14は、決済方法情報が「オンラインカード決済」であると判定した場合には(ステップS48:YES)、出力手段として、オンラインカード決済通知メールを送信する(ステップS49)。具体的に、システム制御部14は、選択した予約情報に含まれるユーザIDに対応する会員情報を、会員情報DB12aから検索する。次いで、システム制御部14は、検索した会員情報からメールアドレスを取得する。次いで、システム制御部14は、オンラインカード決済通知メールを生成する。このとき、システム制御部14は、取得したメールアドレスを、オンラインカード決済通知メールの宛先に設定する。また、システム制御部14は、オンラインカード決済通知メールの本文に、第1希望のクレジットカードで与信を確認することができたため、決済方法がオンラインカード決済から現地決済に変更されない旨の文章を設定する。そして、システム制御部14は、生成したオンラインカード決済通知メールを送信する。システム制御部14は、ステップS49の処理を終えると、ステップS57に移行する。
一方、システム制御部14は、決済方法情報が「オンラインカード決済」ではないと判定した場合には(ステップS48:NO)、出力手段として、決済方法復帰可能通知メールを送信する(ステップS50)。具体的に、システム制御部14は、決済方法復帰可能通知メールを生成する。このとき、システム制御部14は、ステップS49の場合と同様に宛先を設定する。また、システム制御部14は、決済方法復帰可能通知メールの本文に、第1希望のクレジットカードで与信を確認することができたため、現地決済から第1希望のクレジットカードによるオンラインカード決済に戻すことが可能である旨の文章を設定する。また、システム制御部14は、決済方法復帰可能通知メールの本文に、決済方法復帰承認ページのURLを設定する。システム制御部14は、決済方法復帰承認ページのURLに、選択した予約情報に含まれる予約番号を付加する。そして、システム制御部14は、生成した決済方法復帰可能通知メールを送信する。システム制御部14は、ステップS50の処理を終えると、ステップS57に移行する。
決済方法復帰可能通知メールを受信したユーザが、本文に設定されたURLを選択すると、ユーザ端末4は宿泊施設予約サーバ1へURLを含むリクエストを送信し、これに応じて、システム制御部14は、決済方法復帰承認ページをユーザ端末4へ送信する。ここで、ユーザが、承認するボタンを選択すると、システム制御部14は、予約情報DB12cから、受信したリクエストに含まれるURLに付加された予約番号に対応する予約情報を検索する。次いで、システム制御部14は、検索した予約情報に含まれる決済方法情報を「オンラインカード決済」に変更する。
ステップS51において、システム制御部14は、選択した予約情報に、第2クレジットカード情報が設定されているか否かを判定する。このとき、システム制御部14は、第2クレジットカード情報が設定されていないと判定した場合には(ステップS51:NO)、ステップS55に移行する。一方、システム制御部14は、第2クレジットカード情報が設定されていると判定した場合には(ステップS51:YES)、選択した予約情報に含まれる第2クレジットカード情報に基づいて、第2希望のクレジットカードの与信を確認する(ステップS52)。この処理の内容は、ステップS45の処理内容と基本的に同様である。ただし、システム制御部14は、選択した予約情報に含まれる第2クレジットカード情報を、与信確認リクエストに設定する。
次いで、システム制御部14は、与信を確認することができたか否かを判定する(ステップS53)。このとき、システム制御部14は、与信を確認することができなかったと判定した場合には(ステップS53:NO)、ステップS55に移行する。一方、システム制御部14は、与信を確認することができたと判定した場合には(ステップS53:YES)、ステップS52において決済サーバ2から受信した与信確認応答に含まれる承認番号で、選択した予約情報に含まれる宿泊料金承認番号を上書きする。次いで、システム制御部14は、選択した予約情報に含まれる与信確認結果にOKを設定する。また、システム制御部14は、選択した予約情報に含まれる利用カード種別に「第2カード」を設定する(ステップS54)。次いで、システム制御部14は、ステップS57に移行する。
ステップS55において、システム制御部14は、選択した予約情報に含まれる決済方法情報を「現地決済」に変更する。また、システム制御部14は、選択した予約情報に含まれる再々与信確認フラグをOFFに設定する。
次いで、システム制御部14は、出力手段として、現地決済通知メールを送信する(ステップS56)。具体的に、システム制御部14は、現地決済通知メールを生成する。このとき、システム制御部14は、ステップS49の場合と同様に宛先を設定する。また、システム制御部14は、現地決済通知メールの本文に、決済方法がオンラインカード決済から現地決済に変更された旨の文章を設定する。そして、システム制御部14は、生成した現地決済通知メールを送信する。システム制御部14は、ステップS56の処理を終えると、ステップS57に移行する。なお、システム制御部14は、予約された宿泊施設の提供者に対しても、現地決済通知メールを送信してもよい。
ステップS57において、システム制御部14は、ステップS41で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する。このとき、システム制御部14は、まだ選択していない予約情報があると判定した場合には(ステップS57:YES)、まだ選択していない予約情報のうち1つを選択する(ステップS58)。次いで、システム制御部14は、ステップS43に移行する。システム制御部14は、ステップS43〜S58の処理を繰り返すことにより、今日再与信確認が必要な各予約について再与信確認を行う。そして、システム制御部14は、全ての予約情報を選択したと判定した場合には(ステップS57:NO)、再与信確認処理を終了させる。
図10は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14の再々与信確認処理における処理例を示すフローチャートである。
図10に示すように、システム制御部14は、予約情報DB12cから、再々与信確認フラグがONに設定されている予約情報のうち、再々与信確認日が今日である予約情報を検索する(ステップS61)。次いで、システム制御部14は、検索した予約情報のうち1つを選択する(ステップS62)。次いで、システム制御部14は、選択した予約情報が対応する予約について、再与信確認により確保された与信を取り消す(ステップS63)。この処理の内容は、図9に示す再与信確認処理のステップS44の処理内容と同様である。
次いで、システム制御部14は、選択した予約情報に含まれる利用カード種別が「第1カード」であるか否かを判定する(ステップS64)。このとき、システム制御部14は、利用カード種別が「第1カード」であると判定した場合には(ステップS64:YES)、選択した予約情報に含まれる第1クレジットカード情報を取得する(ステップS65)。次いで、システム制御部14は、ステップS67に移行する。一方、システム制御部14は、利用カード種別が「第1カード」ではないと判定した場合には(ステップS64:NO)、選択した予約情報に含まれる第2クレジットカード情報を取得する(ステップS66)。次いで、システム制御部14は、ステップS67に移行する。
ステップS67において、システム制御部14は、ステップS65またはS66において取得したクレジットカード情報に基づいて、与信を確認する。この処理の内容は、図7に示す予約処理のステップS4の処理内容と同様である。次いで、システム制御部14は、与信を確認することができたか否かを判定する(ステップS68)。このとき、システム制御部14は、与信を確認することができたと判定した場合には(ステップS68:YES)、ステップS67において決済サーバ2から受信した与信確認応答に含まれる承認番号で、選択した予約情報に含まれる宿泊料金承認番号を上書きする。次いで、システム制御部14は、ステップS71に移行する。
一方、システム制御部14は、与信を確認することができなかったと判定した場合には(ステップS68:NO)、選択した予約情報に含まれる与信確認結果にNGを設定する。また、システム制御部14は、選択した予約情報に含まれる決済方法情報を「現地決済」に変更する(ステップS69)。次いで、システム制御部14は、現地決済通知メールを送信する(ステップS70)。この処理の内容は、図9に示す再与信確認処理のステップS56の処理内容と同様である。システム制御部14は、ステップS70の処理を終えると、ステップS71に移行する。
ステップS71において、システム制御部14は、ステップS61で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する。このとき、システム制御部14は、まだ選択していない予約情報があると判定した場合には(ステップS71:YES)、まだ選択していない予約情報のうち1つを選択する(ステップS72)。次いで、システム制御部14は、ステップS63に移行する。システム制御部14は、ステップS63〜S72の処理を繰り返すことにより、今日再々与信確認が必要な各予約について再々与信確認を行う。そして、システム制御部14は、全ての予約情報を選択したと判定した場合には(ステップS71:NO)、再々与信確認処理を終了させる。
図11は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14のオプション料金登録処理における処理例を示すフローチャートである。
オプション料金が発生した場合、宿泊施設の提供者は、オプション料金を登録するために、宿泊施設端末3を操作する。このとき、提供者は、オプション料金、予約番号等を入力する。すると、宿泊施設端末3は、オプション料金登録リクエストを宿泊施設予約サーバ1へ送信する。オプション料金登録処理は、宿泊施設予約サーバ1がオプション料金登録リクエストを受信したときに開始される。
図11に示すように、システム制御部14は、予約情報DB12cから、オプション料金登録リクエストに含まれる予約番号に対応する予約情報を検索する。次いで、システム制御部14は、検索した予約情報に含まれる決済方法情報に「オンラインカード決済」が設定され、且つ、検索した予約情報に含まれる与信確認結果にOKが設定されているか否かを判定する(ステップS81)。
このとき、システム制御部14は、決済方法情報に「オンラインカード決済」が設定されていないと判定した場合、または、与信確認結果にOKが設定されていないと判定した場合には(ステップS81:NO)、与信確認エラー終了ページを、オプション料金登録リクエストの送信元の宿泊施設端末3へ送信する(ステップS82)。与信確認エラー終了ページは、オプション料金について与信を確認することができなかった旨のメッセージを表示するWebページである。システム制御部14は、ステップS82の処理を終えると、オプション料金登録処理を終了させる。
一方、システム制御部14は、決済方法情報に「オンラインカード決済」が設定されており、且つ、与信確認結果にOKが設定されていると判定した場合には(ステップS81:YES)、検索した予約情報に含まれる利用カード種別が「第1カード」であるか否かを判定する(ステップS83)。このとき、システム制御部14は、利用カード種別が「第1カード」であると判定した場合には(ステップS83:YES)、検索した予約情報に含まれる第1クレジットカード情報を取得する(ステップS84)。次いで、システム制御部14は、ステップS86に移行する。一方、システム制御部14は、利用カード種別が「第1カード」ではないと判定した場合には(ステップS83:NO)、検索した予約情報に含まれる第2クレジットカード情報を取得する(ステップS85)。次いで、システム制御部14は、ステップS86に移行する。
ステップS86において、システム制御部14は、ステップS84またはS85において取得したクレジットカード情報に基づいて、オプション料金を決済するための与信を確認する。この処理の内容は、図7に示す予約処理のステップS4の処理内容と基本的に同様である。ただし、システム制御部14は、宿泊料金の代わりに、オプション料金を与信確認リクエストに設定する。
次いで、システム制御部14は、与信を確認することができたか否かを判定する(ステップS87)。このとき、システム制御部14は、与信を確認することができなかったと判定した場合には(ステップS87:NO)、ステップS82に移行する。一方、システム制御部14は、与信を確認することができたと判定した場合には(ステップS87:YES)、ステップS86において決済サーバ2から受信した与信確認応答に含まれる承認番号をオプション料金承認番号として、検索した予約情報中に設定する。次いで、システム制御部14は、検索した予約情報に含まれるオプション料金決済フラグをONに設定する。また、システム制御部14は、オプション料金登録リクエストに含まれるオプション料金を、検索した予約情報中に設定する(ステップS88)。次いで、システム制御部14は、与信確認正常終了ページを、オプション料金登録リクエストの送信元の宿泊施設端末3へ送信する(ステップS89)。与信確認正常終了ページは、オプション料金について与信を確認することができた旨のメッセージを表示するWebページである。システム制御部14は、ステップS89の処理を終えると、オプション料金登録処理を終了させる。
図12は、本実施形態に係る宿泊施設予約サーバ1のシステム制御部14の決済処理における処理例を示すフローチャートである。
図12に示すように、システム制御部14は、予約情報DB12cから、決済方法情報に「オンラインカード決済」が設定されている予約情報のうち、チェックアウト日の翌日が今日である予約情報を検索する(ステップS91)。次いで、システム制御部14は、検索した予約情報のうち1つを選択する(ステップS92)。次いで、システム制御部14は、選択した予約情報に含まれる利用カード種別が「第1カード」であるか否かを判定する(ステップS93)。このとき、システム制御部14は、利用カード種別が「第1カード」であると判定した場合には(ステップS93:YES)、検索した予約情報に含まれる第1クレジットカード情報を取得する(ステップS94)。次いで、システム制御部14は、ステップS96に移行する。一方、システム制御部14は、利用カード種別が「第1カード」ではないと判定した場合には(ステップS93:NO)、検索した予約情報に含まれる第2クレジットカード情報を取得する(ステップS95)。次いで、システム制御部14は、ステップS96に移行する。
ステップS96において、システム制御部14は、選択した予約情報に含まれるオプション決済フラグがONに設定されているか否かを判定する。このとき、システム制御部14は、オプション決済フラグがONに設定されていないと判定した場合には(ステップS96:NO)、取得したクレジットカード情報に基づいて、選択した予約情報に含まれる宿泊料金を決済する(ステップS97)。具体的に、システム制御部14は、決済リクエストを決済サーバ2へ送信する。決済リクエストは、取得したクレジットカード情報、利用額、承認番号等を含む。システム制御部14は、利用額及び承認番号として、選択された予約情報に含まれる宿泊料金及び宿泊料金承認番号を設定する。決済サーバ2は、決済リクエストを受信すると、決済リクエストに含まれる承認番号に対応してユーザの口座から引き落とす利用料金を、決済リクエストに含まれる宿泊料金で確定する処理を行う。システム制御部14は、ステップS97の処理を終えると、ステップS99に移行する。
一方、システム制御部14は、オプション決済フラグがONに設定されていると判定した場合には(ステップS96:YES)、決済手段として、取得したクレジットカード情報に基づいて、選択した予約情報に含まれる宿泊料金及びオプション料金を含む利用料金を決済する(ステップS98)。具体的に、システム制御部14は、ステップS97と同様の方法で、宿泊料金を決済する。また、システム制御部14は、選択された予約情報に含まれるオプション料金及びオプション料金承認番号を設定した決済リクエストを決済サーバ2へ送信する。これにより、システム制御部14は、オプション料金を決済する。システム制御部14は、ステップS98の処理を終えると、ステップS99に移行する。
ステップS99において、システム制御部14は、ステップS91で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する。このとき、システム制御部14は、まだ選択していない予約情報があると判定した場合には(ステップS99:YES)、まだ選択していない予約情報のうち1つを選択する(ステップS100)。次いで、システム制御部14は、ステップS93に移行する。システム制御部14は、ステップS93〜S100の処理を繰り返すことにより、今日決済が必要な各予約について利用料金の決済を行う。そして、システム制御部14は、全ての予約情報を選択したと判定した場合には(ステップS99:NO)、決済処理を終了させる。
以上説明したように、本実施形態によれば、宿泊施設予約サーバ1のシステム制御部14が、オンラインカード決済が指定される予約の要求に対し、指定されたクレジットカードの有効性を確認することができなかった場合、予約を受け付け、指定されたクレジットカードのクレジットカード情報を記憶部12に記憶させる。予約が受け付けられた後、システム制御部14が、記憶部12に記憶された情報に基づいて、指定されたクレジットカードの有効性を確認し、有効であると確認することができた場合、決済方法を、指定されたクレジットカードでの決済にすることを示すオンラインカード決済通知メールまたは決済方法復帰通知メールを送信し、有効であると確認することができなかった場合、決済方法を、指定されたクレジットカードでの決済とは異なる方法にすることを示す現地決済通知メールを送信する。従って、ユーザが利用したいクレジットカードで利用料金を決済する支払うための信用が予約時になかった場合であっても、その後信用が戻った場合に、ユーザが利用したいクレジットカードによる決済に決済方法を設定することができる。そのため、宿泊施設予約サーバ1は、ユーザが利用したいクレジットカードでの決済が可能となる予約を受け付けることができる。
また、システム制御部14が、予約が受け付けられた宿泊施設の利用日数が与信日数以上である場合、予約が受け付けられた宿泊施設のチェックイン日の前日までに、指定されたクレジットカードの有効性を確認する。従って、与信期間内に決済されるようにクレジットカードの有効性を確認すると確認日がチェックイン日以降になる利用日数の予約について、チェックイン日よりも前に与信を確認することができる。そのため、宿泊施設の提供者は、ユーザがクレジットカードでの利用料金の支払いが可能であることが確保された状態で、宿泊施設の提供を開始することができる。
また、システム制御部14が、予約が受け付けられた宿泊施設の利用日数が与信日数以上である場合、再与信確認によって有効であると確認することができた後、決済日までの日数が与信日数以下になる日以降に、記憶部12に記憶された第1クレジットカード情報に基づいて、指定されたクレジットカードの有効性を確認し、有効であると確認することができなかった場合、現地決済通知メールを出力する。従って、利用料金の決済の安全性を高めることができる。
また、システム制御部14が、再与信確認によってオンラインカード決済が有効であると確認することができた宿泊料金以外に、予約された宿泊施設の利用によってオプション料金が発生した場合、記憶部12に記憶されたクレジットカード情報に基づいて、宿泊料金と発生したオプション料金とを含む利用料金を、指定されたクレジットカードで決済する。従って、ユーザが宿泊施設を利用した際に新たに料金が発生した場合に、ユーザは、決済の手続を行わなくても、ユーザが利用したいクレジットカードで決済することができる。
また、システム制御部14が、予約の要求に対して指定されたクレジットカードが有効であると確認することができなかった場合、エラー種別が「限度額オーバー」であるか否かを判定し、エラー種別が「限度額オーバー」であると判定した場合に、予約を受け付け、指定されたクレジットカードの情報を記憶部12に記憶させる。従って、宿泊施設予約サーバ1が不必要に再与信確認を行うことを抑制することができる。
また、システム制御部14が、オンラインカード決済が指定された予約時にクレジットカードが有効であると確認することができなかった場合、エラー種別が「限度額オーバー」であるか否かを判定し、エラー種別が「限度額オーバー」であると判定した場合に、再与信確認を行う。従って、宿泊施設予約サーバ1が不必要に再与信確認を行うことを抑制することができる。
なお、上記実施形態において、宿泊施設予約サーバ1は、与信枠クリア日に再与信確認を行っていた。しかしながら、宿泊施設予約サーバ1は、1ヶ月の間のうち、宿泊料金を決済する信用が回復する蓋然性が高い日を推定してもよい。この日を、「信用回復日」という。信用回復日は、与信枠クリア日であることもある。そして、宿泊施設予約サーバ1は、推定した信用回復日に、再与信確認を行ってもよい。例えば、宿泊施設予約サーバ1は、与信を確認することができなかった予約日と、再与信確認において与信を確認することができた日と、を履歴として記録する。予約日の翌日から再与信確認の日までの間に、宿泊料金を決済する信用が回復した日が存在する。そこで、宿泊施設予約サーバ1は、この間に含まれる日の中から、信用回復日を推定する。宿泊施設予約サーバ1は、宿泊料金を決済する信用が回復する蓋然性が高い日を推定し、推定した日に再与信確認を行ことにより、与信を確認することができる確率を高めることができる。また、信用が回復する蓋然性が高い日を推定することにより、クレジットカード会社が与信枠クリア日を公表していない場合にも有効である。
具体的には、例えば、記憶部12に、与信確認履歴DBが構築される。与信確認履歴DBには、与信を確認することができなかった予約日を含む与信確認履歴と、再与信確認において与信を確認することができた日を含む与信確認履歴とが登録される。より詳細に、与信確認履歴には、予約番号、与信確認日、与信確認種別及びクレジットカード会社情報が対応付けて登録される。予約番号は、与信確認が行われた予約を示す。与信確認日は、与信を確認することができなかった予約日、または、与信を確認することができた再与信確認日の何れかである。与信確認種別は、行われた与信確認の種別である。与信確認種別には、「第1」または「第2」の何れかが設定される。「第1」は、予約時の与信確認を示す。「第2」は、再与信確認を示す。クレジットカード会社情報は、与信確認が行われたクレジットカードの発行元のクレジットカード会社を示す。
図7に示す予約処理のステップS8において、システム制御部14は、エラー種別が「限度額オーバー」であると判定した場合には(ステップS8:YES)、ステップS10を実行しないで、ステップS11を実行する。図8に示す決済方法変更予約処理において、システム制御部14は、ステップS28の処理を終えた後、記憶制御手段として、与信確認履歴を登録する。具体的に、システム制御部14は、与信確認日として予約日を設定する。また、システム制御部14は、与信確認種別に「第1」を設定する。また、システム制御部14は、予約を要求したユーザIDに対応付けて記憶部12に記憶しておいたカード情報から、クレジットカード会社情報を取得する。そして、システム制御部14は、新しい予約番号、再与信確認日、再与信確認種別及びクレジットカード会社情報を含む与信確認履歴を、与信確認履歴DBに登録する。図9に示す再与信確認処理のステップS46において、システム制御部14は、与信を確認することができたと判定した場合には(ステップS46:YES)、記憶制御手段として、与信確認履歴を登録する。具体的に、システム制御部14は、選択した予約情報から予約番号、再与信確認日を取得する。また、システム制御部14は、再与信確認種別に「第2」を設定する。また、システム制御部14は、選択した予約情報に含まれる第1クレジットカード情報から、クレジットカード会社情報を取得する。そして、システム制御部14は、予約番号、再与信確認日、再与信確認種別及びクレジットカード会社情報を含む与信確認履歴を、与信確認履歴DBに登録する。
決済方法変更予約処理のステップS29において、システム制御部14は、再与信確認日に与信枠クリア日を設定しない。次いで、システム制御部14は、取得したクレジットカード会社情報を含む与信確認履歴を、与信確認履歴DB12から検索する。次いで、システム制御部14は、推定手段として、検索した与信確認履歴に基づいて、取得したクレジットカード会社情報が示すクレジットカード会社が発行するクレジットカードの信用回復日を推定する。クレジットカード会社情報ごとに推定する理由は、クレジットカード会社情報ごとに、与信枠クリア日等の信用回復日が異なる場合があるからである。具体的に、システム制御部14は、検索した与信確認履歴から、同一の予約情報を含む与信確認履歴の組を抽出する。同一の予約情報を含む与信確認履歴の組は、与信確認種別が「第1」である与信確認履歴と、与信確認種別が「第2」である与信確認履歴の組み合わせである。システム制御部14は、予約日と再与信確認の日との中間日を特定する。具体的に、システム制御部14は、与信確認種別が「第1」である与信確認履歴に含まれる与信確認日から、与信確認種別が「第2」である与信確認履歴に含まれる与信確認日までの日数を算出する。次いで、システム制御部14は、算出した日数の半分を、与信確認種別が「第1」である与信確認履歴に含まれる与信確認日に加算して、中間日を算出する。このとき、システム制御部14は、算出された年月日のうち日のみを中間日とする。例えば、予約日が2012年1月25日であり、再与信確認日が2012年2月10日であるとする。この場合、1月25日から8日後の2012年2月2日が中間日となる。ただし、最終的な中間日は、2012年2月2日から2012年2月を除いた2日である。システム制御部14は、抽出した与信確認履歴の組ごとに、中間日の算出を行う。次いで、システム制御部14は、1ヶ月間における中間日の分布に基づいて、中間日が集中する日を信用回復日として特定する。例えば、システム制御部14は、中間日が最も多く分布する日を信用回復日としてもよい。また、システム制御部14は、例えば、算出された中間日のうち所定割合以上の中間日が分布する日を信用回復日としてもよい。この場合、システム制御部14は、複数の信用回復日を特定してもよい。また、システム制御部14は、例えば、1ヶ月間を複数の期間に分割し、所定割合以上の中間日が分布する期間を特定してもよい。そして、システム制御部14は、特定した期間の中央の日を信用回復日としてもよいし、特定した期間の開始日から終了日までのそれぞれを信用回復日としてもよい。
システム制御部14は、信用回復日を推定すると、明日からチェックイン日の前日までに、推定した信用回復日があるか否かを判定する。このとき、システム制御部14は、明日からチェックイン日の前日までの間に信用回復日があると判定した場合には、オンラインカード決済管理情報に含まれる再与信確認日に、推定した信用回復日を設定する。明日からチェックイン日の前日までの間に信用回復日が複数ある場合、システム制御部14は、何れかの信用回復日を設定する。このとき、システム制御部14は、信用が回復する蓋然性が最も高い信用回復日を設定してもよい。例えば、システム制御部14は、明日からチェックイン日の前日までの間に含まれる信用回復日のうち中間日が最も多く分布する日を設定してもよい。一方、システム制御部14は、明日からチェックイン日の前日までの間に信用回復日がないと判定した場合には、明日からチェックイン日の前日までの間の何れかの日を、再与信確認日に設定してもよい。システム制御部14は、再与信確認日の設定を行うと、ステップS30に移行する。
なお、上記実施形態においては、宿泊施設の提供に対して本発明を適用していた。しかしながら、予約時に利用日が決定されるサービスであれば、如何なるサービスに対しても本発明を適用することができる。このようなサービスとしては、例えば、ゴルフ場等の競技施設の提供や、航空機、列車、船舶、乗用車等の交通機関による人の輸送等がある。