(57)【要約】【課題】利用料金の決済の安全性を保ちつつ、クレジットカードでの決済が指定される予約として、予約日から利用日までの日数が与信期間に相当する日数を超える予約を受け付ける。【解決手段】情報処理装置は、利用日までの日数が与信期間の日数を超える予約が要求された場合、指定されたクレジットカードの有効性を確認する。このとき、情報処理装置は、有効であると確認することができた場合、予約を受け付け、指定されたクレジットカードの情報を記憶手段に記憶させる。情報処理装置は、予約が受け付けられたサービスの利用日までの日数が与信期間の日数以下になる日以降に、記憶手段に記憶されたクレジットカードの情報に基づいて、予約時に指定されたクレジットカードの有効性を確認する。このとき、情報処理装置は、有効であると確認することができなかった場合、決済方法を、指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する。【選択図】図２
2013182314.tif 000002
【特許請求の範囲】
【請求項１】
サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段と、
前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段と、
前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段と、
前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記第２確認手段により有効であると確認することができなかった後、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第３確認手段を更に備え、
前記出力手段は、前記第３確認手段により有効であると確認することができた場合、前記決済方法を前記指定されたクレジットカードで決済する方法にすることを示す情報を出力することを特徴とする情報処理装置。
【請求項３】
請求項２に記載の情報処理装置において、
前記第３確認手段により有効であると確認することができた前記利用料金以外に、予約されたサービスの利用によって料金が発生した場合、前記記憶手段に記憶された前記情報に基づいて、前記発生した料金を含む前記利用料金を前記指定されたクレジットカードで決済する決済手段を更に備えることを特徴とする情報処理装置。
【請求項４】
請求項２または請求項３に記載の情報処理装置において、
前記予約手段により予約が受け付けられたサービスの利用日数が前記与信日数以上である場合、前記第３確認手段により有効であると確認することができた後、予約が受け付けられたサービスの利用開始日の前日までに、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第４確認手段を更に備え、
前記出力手段は、前記第４確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力することを特徴とする情報処理装置。
【請求項５】
請求項４に記載の情報処理装置において、
前記第４確認手段により有効であると確認することができた後、前記利用料金の決済日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第５確認手段を更に備え、
前記出力手段は、前記第５確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力することを特徴とする情報処理装置。
【請求項６】
請求項２乃至５の何れか１項に記載の情報処理装置において、
前記第２確認手段により有効であると確認することができなかった場合、有効であると確認することができなかった理由が、前記利用料金が前記指定されたクレジットカードの利用可能額を超えることであるか否かを判定する判定手段を更に備え、
前記第３確信手段は、前記理由が、前記利用料金が前記利用可能額を超えることであると前記判定手段により判定した場合に、前記指定されたクレジットカードの有効性を確認することを特徴とする情報処理装置。
【請求項７】
請求項２乃至６の何れか１項に記載の情報処理装置において、
前記第２確認手段による有効性の確認日と、前記第３確認手段による有効性の確認日とを、確認日記憶手段に記憶させる記憶制御手段と、
前記確認日記憶手段に記憶された前記確認日に基づいて、前記指定されたクレジットカードが有効になる日を推定する推定手段と、
を更に備え、
前記第３確認手段は、前記推定手段により推定された日に、前記指定されたクレジットカードの有効性を確認することを特徴とする情報処理装置。
【請求項８】
コンピュータにより実行される情報処理方法であって、
サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認ステップと、
前記第１確認ステップにおいて有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約ステップと、
前記予約ステップにおいて予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認ステップと、
前記第２確認ステップにおいて有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力ステップと、
を含むことを特徴とする情報処理方法。
【請求項９】
コンピュータを、
サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段、
前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段、
前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段、及び、
前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段、
として機能させることを特徴とする情報処理プログラム。
【請求項１０】
コンピュータを、
サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段、
前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段、
前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段、及び、
前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段、
として機能させる情報処理プログラムがコンピュータ読み取り可能に記録されていることを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、予約されるサービスの利用料金をクレジットカードで決済するための処理を行う情報処理装置及び情報処理方法の技術分野に関する。
【背景技術】
【０００２】
従来、インターネット上で、例えば宿泊施設の宿泊予約等のサービスの利用の予約を受け付ける予約システムが知られている。このような予約システムの中には、オンラインカード決済を可能とするシステムが存在する。予約時にユーザが決済方法としてオンラインカード決済を指定すると、予約システムが、予約されたサービスの利用日以降の日に、クレジットカードによる利用料金の決済の処理を自動的に行う。この場合、ユーザは、サービスの利用時に決済の手続を行う必要がない。
【０００３】
決済方法としてオンラインカード決済が指定された場合、予約システムは、予約時にクレジットカードの有効性の確認を行う。このとき、クレジットカードが有効であると確認された場合には、利用料金に相当する予約枠が確保される。確保された予約枠が有効とされる期間は、与信期間として予め定められている。与信期間が経過した後にサービスの利用日が到来すると、オンラインカード決済での利用料金の決済の安全性を確保することができない場合がある。そのため、予約システムにおいて、サービスの利用日から何日前までの予約でオンラインカード決済が可能であるかが定められている。例えば、非特許文献１には、宿泊施設の予約において、チェックイン日が予約日から９０日以内の予約のみ、ユーザはオンラインカード決済を利用することができる技術が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】株式会社リクルート、“オンラインカード決済とは”、［online］、［平成24年1月17日検索］、インターネット<URL: http://www.jalan.net/jalan/doc/howto/cardkessai.html>
【発明の概要】
【発明が解決しようとする課題】
【０００５】
このように、従来の技術では、ユーザがオンラインカード決済を利用する場合、予約日から利用日までの日数が与信期間に相当する日数を超える予約を受け付けることができなかった。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、利用料金の決済の安全性を保ちつつ、クレジットカードでの決済が指定される予約として、予約日から利用日までの日数が与信期間に相当する日数を超える予約を受け付けることができる情報処理装置、情報処理方法、情報処理プログラム及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段と、前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段と、前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段と、前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段と、を備えることを特徴とする。
【０００８】
この発明によれば、情報処理装置は、予約日から利用日までの日数が与信期間に相当する日数を超える場合であっても、指定されたクレジットカードが有効であることを確認して予約を受け付けることができる。また、指定されたクレジットカードが予約の後に有効ではなくなった場合には、決済方法が変更されるので、利用料金の決済の安全性を保ちつつ予約を維持することができる。
【０００９】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記第２確認手段により有効であると確認することができなかった後、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第３確認手段を更に備え、前記出力手段は、前記第３確認手段により有効であると確認することができた場合、前記決済方法を前記指定されたクレジットカードで決済する方法にすることを示す情報を出力することを特徴とする。
【００１０】
この発明によれば、予約の後に、ユーザが利用したいクレジットカードで利用料金を支払うための信用が一度なくなった場合であっても、その後信用が戻った場合に、決済方法を、ユーザが利用したいクレジットカードによる決済にすることができる。
【００１１】
請求項３に記載の発明は、請求項２に記載の情報処理装置において、前記第３確認手段により有効であると確認することができた前記利用料金以外に、予約されたサービスの利用によって料金が発生した場合、前記記憶手段に記憶された前記情報に基づいて、前記発生した料金を含む前記利用料金を前記指定されたクレジットカードで決済する決済手段を更に備えることを特徴とする。
【００１２】
この発明によれば、ユーザがサービスを利用した際に新たに料金が発生した場合に、ユーザは、決済の手続を行わなくても、ユーザが利用したいクレジットカードで決済することができる。
【００１３】
請求項４に記載の発明は、請求項２または請求項３に記載の情報処理装置において、前記予約手段により予約が受け付けられたサービスの利用日数が前記与信日数以上である場合、前記第３確認手段により有効であると確認することができた後、予約が受け付けられたサービスの利用開始日の前日までに、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第４確認手段を更に備え、前記出力手段は、前記第４確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する
【００１４】
この発明によれば、与信期間内に決済されるようにクレジットカードの有効性を確認すると確認日が利用開始日以降になる利用日数の予約について、利用開始日よりも前にクレジットカードの有効性を確認することができる。そのため、サービスの提供者は、ユーザがクレジットカードでの利用料金の支払いが可能であることが確保された状態で、サービスの提供を開始することができる。また、第４確認手段による有効性の確認によって、与信期間に含まれるサービスの利用日を多くすることができる。
【００１５】
請求項５に記載の発明は、請求項４に記載の情報処理装置において、前記第４確認手段により有効であると確認することができた後、前記利用料金の決済日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第５確認手段を更に備え、前記出力手段は、前記第５確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力することを特徴とする。
【００１６】
この発明によれば、サービスの利用開始日よりも前にクレジットカードが有効であることが確認された後、与信期間内に決済されるようにクレジットカードの有効性が更に確認され、このときに、有効であると確認することができなかった場合には、決済方法を変更することができる。そのため、サービスの利用料金の決済の安全性を高めることができる。
【００１７】
請求項６に記載の発明は、請求項２乃至５の何れか１項に記載の情報処理装置において、前記第２確認手段により有効であると確認することができなかった場合、有効であると確認することができなかった理由が、前記利用料金が前記指定されたクレジットカードの利用可能額を超えることであるか否かを判定する判定手段を更に備え、前記第３確信手段は、前記理由が、前記利用料金が前記利用可能額を超えることであると前記判定手段により判定した場合に、前記指定されたクレジットカードの有効性を確認することを特徴とする。
【００１８】
この発明によれば、第２確認手段によってクレジットカードが有効であると確認することができなかった理由が、予約対象のサービスの利用料金がクレジットカードの利用可能額を超えるという理由である場合には、また再度、クレジットカードの有効性が確認される。クレジットカードの利用可能額は、第２確認手段による有効性の確認時から増加する蓋然性がある。そのため、情報処理装置は、有効性を確認することができる蓋然性が高い予約のみを受け付けることができる。これにより、情報処理装置が不必要にクレジットカードの有効性を再度確認することを抑制することができる。
【００１９】
請求項７に記載の発明は、請求項２乃至６の何れか１項に記載の情報処理装置において、前記第２確認手段による有効性の確認日と、前記第３確認手段による有効性の確認日とを、確認日記憶手段に記憶させる記憶制御手段と、前記確認日記憶手段に記憶された前記確認日に基づいて、前記指定されたクレジットカードが有効になる日を推定する推定手段と、を更に備え、前記第３確認手段は、前記推定手段により推定された日に、前記指定されたクレジットカードの有効性を確認することを特徴とする。
【００２０】
この発明によれば、指定されたクレジットカードが有効になると推定された日に有効性の確認が行われるので、利用料金を支払うための信用が戻ることによってクレジットカードが有効であると確認することができる蓋然性を高めることができる。
【００２１】
請求項８に記載の発明は、コンピュータにより実行される情報処理方法であって、サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認ステップと、前記第１確認ステップにおいて有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約ステップと、前記予約ステップにおいて予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認ステップと、前記第２確認ステップにおいて有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力ステップと、を含むことを特徴とする。
【００２２】
請求項９に記載の発明は、コンピュータを、サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段、前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段、前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段、及び、前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段、として機能させることを特徴とする。
【００２３】
請求項１０に記載の発明は、コンピュータを、サービスの利用日以降にクレジットカードで利用料金が決済される予約として、前記利用日までの日数が前記クレジットカードでの支払いの信用が与えられる期間に相当する与信日数を超える予約が要求された場合、指定された前記クレジットカードの有効性を確認する第１確認手段、前記第１確認手段により有効であると確認することができた場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段、前記予約手段により予約が受け付けられたサービスの利用日までの日数が前記与信日数以下になる日以降に、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する第２確認手段、及び、前記第２確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法に変更することを示す情報を出力する出力手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記録されていることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、情報処理装置は、予約日から利用日までの日数が与信期間に相当する日数を超える場合であっても、指定されたクレジットカードが有効であることを確認して予約を受け付けることができる。また、指定されたクレジットカードが予約の後に有効ではなくなった場合には、決済方法が変更されるので、利用料金の決済の安全性を保ちつつ予約を維持することができる。
【図面の簡単な説明】
【００２５】
【図１】一実施形態に係る情報処理システムＳの概要構成の一例を示す図である。
【図２】予約から決済までの処理の流れを示す図である。
【図３】宿泊施設の利用日数が与信期間の日数以上である場合の予約から決済までの処理の流れを示す図である。
【図４】宿泊施設の利用日数が与信期間の日数以上である場合の予約から決済までの処理の流れを示す図である。
【図５】一実施形態に係る宿泊施設予約サーバ１の概要構成の一例を示すブロック図である。
【図６】（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図であり、（ｂ）は、宿泊施設情報ＤＢ１２ｂに登録される内容の一例を示す図であり、（ｃ）は、予約情報ＤＢ１２ｃに登録される内容の一例を示す図であり、（ｄ）は、再与信確認履歴ＤＢ１２ｄに登録される内容の一例を示す図である。
【図７】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の予約処理における処理例を示すフローチャートである。
【図８】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の再与信確認処理における処理例を示すフローチャートである。
【図９】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の再与信確認処理における処理例を示すフローチャートである。
【図１０】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の決済方法変更処理における処理例を示すフローチャートである。
【図１１】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４のオプション料金登録処理における処理例を示すフローチャートである。
【図１２】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の決済処理における処理例を示すフローチャートである
【発明を実施するための形態】
【００２６】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、情報処理システムに対して本発明を適用した場合の実施形態である。
【００２７】
［１．情報処理システムの構成及び機能概要］
先ず、本実施形態に係る情報処理システムＳの構成及び機能概要について、図１を用いて説明する。図１は、本実施形態に係る情報処理システムＳの概要構成の一例を示す図である。
【００２８】
図１に示すように、情報処理システムＳは、宿泊施設予約サーバ１と、決済サーバ２と、複数の宿泊施設端末３と、複数のユーザ端末４と、を含んで構成されている。そして、宿泊施設予約サーバ１と、決済サーバ２、宿泊施設端末３及びユーザ端末４とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【００２９】
宿泊施設予約サーバ１は、宿泊施設予約サイトに関する各種処理を実行するサーバ装置である。宿泊施設予約サーバ１は、本発明における情報処理装置の一例である。宿泊施設予約サイトは、宿泊施設の宿泊の予約の受け付けを行うＷｅｂサイトである。宿泊施設予約サイトは、複数の宿泊施設から予約の受け付けを委託されている。宿泊施設予約サーバ１は、ユーザ端末４からのリクエストに応じて、例えば、宿泊施設予約サイトのＷｅｂページを送信したり、宿泊施設の検索や、宿泊の予約等に関する処理を行ったりする。また、宿泊施設予約サーバ１は、決済サーバ２へリクエストを送信することにより、例えば、クレジットカードの有効性を確認したり、宿泊施設の宿泊料金の決済する処理を行ったりする。
【００３０】
決済サーバ２は、クレジットカードでの決済に関する各種処理を実行するサーバ装置である。決済サーバ２は、宿泊施設予約サーバ１からのリクエストに基づいて、例えば、クレジットカードの与信の承認の判定を行ったり、決済の処理を行ったりする。なお、図１は、一台の決済サーバ２のみを示しているが、例えば、宿泊施設予約サイトにおいて利用可能なクレジットカードの発行元のクレジットカード会社ごとに決済サーバ２が設けられている。
【００３１】
宿泊施設端末３は、宿泊施設予約サイトに予約の委託をしている宿泊施設の提供者が利用する端末装置である。宿泊施設端末３は、提供者からの操作に基づいて宿泊施設予約サーバ１等のサーバ装置にアクセスする。これにより、宿泊施設端末３は、サーバ装置からＷｅｂページを受信して表示する。宿泊施設端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。提供者は、宿泊施設端末３を利用することにより、例えば、宿泊施設の情報を宿泊施設予約サイトに登録したり、宿泊施設の予約状況を確認したりする。
【００３２】
ユーザ端末４は、宿泊施設予約サイトを利用するユーザの端末装置である。ユーザ端末４は、ユーザからの操作に基づいて宿泊施設予約サーバ１にアクセスすることにより、宿泊施設予約サーバ１からＷｅｂページを受信して表示する。ユーザ端末４には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末４としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
【００３３】
［２．オンラインカード決済での予約］
ユーザは、宿泊施設予約サイトで宿泊施設の利用を予約するとき、宿泊施設の決済方法を指定することができる。決済方法としては、現地決済とオンラインカード決済とがある。現地決済においては、ユーザが、宿泊施設にチェックインするときやチェックアウトするときに、宿泊施設で決済を行う。このとき、ユーザは、例えば、現金決済やクレジットカード決済等を選択することができる。オンラインカード決済では、ユーザが指定したクレジットカードで宿泊施設予約サーバ１が宿泊料金を決済する。本実施形態において、オンラインカード決済の決済日は、チェックアウト日の翌日である。オンラインカード決済で決済された宿泊料金は、例えば、宿泊施設予約サイトから宿泊施設の口座へ振り込まれる。ユーザは、オンラインカード決済を指定した場合、宿泊施設を利用した際に宿泊施設で決済の手続を行わないで済ませることができる。なお、オンラインカード決済の決済日は、チェックアウト日の翌日に限られるものではない。オンラインカード決済の決済日は、チェックイン日以降の何れかの日であればよい。チェックイン日以降とは、チェックイン日と、チェックイン日よりも後の日とを含む。
【００３４】
ユーザがオンラインカード決済を指定して予約を要求した場合、宿泊施設予約サーバ１は、ユーザから指定されたクレジットカードの有効性を確認する。その理由は、指定されたクレジットカードで宿泊料金の支払い能力がユーザにあるかを判断するためである。また、宿泊料金に相当する与信枠を確保するためである。クレジットカードの有効性の確認には、ユーザが指定したクレジットカードの情報が、正規に発効されたクレジットカードの情報と一致するか否かの確認、クレジットカードの有効期限が切れていないかの確認、現時点でのクレジットカードの利用可能額が宿泊料金以上であるか否かの確認を含む。クレジットカードの利用可能額とは、クレジットカードの利用限度額から、現在確保されている与信枠に相当する金額を差し引いて得られる額である。クレジットカードの有効性を確認する処理は、オーソリ処理と呼ばれている。オーソリは、Authorizationの略語である。本実施形態においては、クレジットカードの有効性を確認することを、クレジットカードの与信を確認するという。与信を確認することができると、指定されたクレジットカードで利用代金の支払いに対する信用が与えられる。つまり、与信枠に相当する金額を決済することが可能であることが保証される。ただし、確認された与信は所定の期間のみ有効であり、所定の期間を過ぎると無効となる。この期間が与信期間である。与信期間は、クレジットカードでの支払いの信用が与えられる期間である。与信期間が経過すると、確保された与信枠が消滅する。与信期間の日数は予め定められている。例えば、本実施形態において、与信期間の日数は３０日である。しかしながら、与信期間の日数は、３０日以外であってもよい。なお、与信期間の日数は、本発明における与信日数の一例である。
【００３５】
ユーザが宿泊施設の予約を行った日を予約日という。予約日からチェックアウト日の翌日である決済日までの日数が与信期間の日数以下である場合、宿泊施設予約サーバ１は、予約時に確保した与信枠に基づいて、決済日に宿泊料金を決済することができる。一方、予約日から決済日までの日数が与信期間の日数を超える場合、決済日より前に与信枠が消滅する。すると、決済日にクレジットカードで宿泊料金を決済することができない場合がある。
【００３６】
予約日から決済日までの日数が与信期間の日数を超える場合であっても、予約日からチェックイン日までの日数が与信期間の日数以下であれば、宿泊料金の決済の安全性をある程度保つことができる。その理由は、ユーザが指定したクレジットカードでの与信が確認されている状態でチェックイン日にユーザが宿泊施設の利用を開始するからである。例えば、ユーザが宿泊施設を利用している期間中にクレジットカードでの支払い能力がなくなった場合、宿泊施設の提供者が、宿泊施設に滞在しているユーザに直接決済を求めればよい。また、ユーザが予約をキャンセルする場合や、ユーザが何の連絡もなくチェックイン日になっても宿泊施設に現れない場合がある。この場合は、例えば、宿泊施設予約サーバ１が、宿泊施設の提供者からの要求に基づき、確保されている与信枠内で与信期間内にキャンセル料金を決済すればよい。
【００３７】
宿泊料金の決済の安全性を保つために、予約日からチェックイン日（または、決済日）までの日数が与信期間の日数を超える場合、宿泊施設予約サーバ１が、オンラインカード決済をユーザが利用することができないように制御することが考えられる。しかしながら、ユーザは、宿泊施設の利用日よりも相当日数前に予約をしたい場合がある。このような場合に、オンラインカード決済を利用することができないと、ユーザにとって不便である。また、ユーザは、宿泊施設予約サイトでの予約自体をやめてしまう場合がある。すると、予約が行われなかった分、宿泊施設の提供者は、宿泊施設の提供の機会を失ってしまう。
【００３８】
情報処理システムＳにおいては、ユーザがオンラインカード決済を指定して予約日からチェックイン日までの日数が与信期間の日数を超える予約が要求された場合、宿泊施設予約サーバ１が、その時点で与信確認を行い、与信を確認することができた場合には、予約を受け付ける。このとき、宿泊施設予約サーバ１は、ユーザから指定されたクレジットカードの情報を記憶しておく。その後、宿泊施設予約サーバ１は、チェックイン日までの日数が与信期間の日数以下になった日以降に、記憶しておいたクレジットカードの情報に基づいて、与信確認を再度行う。２回目以降の与信確認を、「再与信確認」という。１回目の再与信確認を、「第１回再与信確認」という。宿泊施設予約サーバ１は、第１回再与信確認において与信を確認することができなかった場合には、受け付けた予約を維持しつつ、決済方法を変更することを示す情報を出力する。
【００３９】
上述した処理により、宿泊施設予約サーバ１は、オンラインカード決済が指定される予約として、予約日からチェックイン日までの日数が与信期間の日数を超える予約を、宿泊料金の決済の安全性を高めつつ受け付けることができる。具体的に、宿泊施設予約サーバ１は、予約時に与信を確認することにより、クレジットカードの有効性やその時点でのユーザの支払い能力を確認することができる。また、第１回再与信確認により、与信を確認することができた場合には、ユーザが指定したクレジットカードでの与信が確認されている状態でチェックイン日にユーザが宿泊施設の利用を開始する。そのため、宿泊料金の決済の安全性を高めることができる。一方、宿泊施設予約サーバ１は、第１回再与信確認により、与信を確認することができなかった場合には、予約時に指定されたクレジットカードによる決済とは別の方法に決済方法を変更することができる。ユーザにとっては、第１回再与信確認の際、決済に利用したいクレジットカードの情報をユーザが再度指定しなくてもよいという利点がある。
【００４０】
なお、本実施形態においては、宿泊施設予約サーバ１は、予約を受け付けて第１回再与信確認を行う対象を、予約日から決済日までの日数が与信期間の日数を超える予約にまで広げる。そして、宿泊施設予約サーバ１は、決済日までの日数が与信期間の日数以下になった日以降に、第１回再与信確認を行う。つまり、宿泊施設予約サーバ１は、チェックイン日を基準とするのではなく、決済日を基準として処理を行う。これにより、宿泊料金の決済の安全性をより高めることができる。その理由は、第１回再与信確認により与信を確認することができた場合には、このときに確保された与信枠に基づいて、宿泊施設予約サーバ１が決済日に宿泊料金を決済することができるからである。
【００４１】
以下に、予約から決済までの処理の概要を説明する。図２は、予約から決済までの処理の流れを示す図である。なお、図２は、与信期間の日数が３０日である場合の例を示す。また、図２は、与信を確認することができた場合を、「ＯＫ」で示し、与信を確認することができなかった場合を、「ＮＧ」で示している。
【００４２】
図２に示すように、ユーザが、チェックイン日及びチェックアウト日を指定する。その結果、今日から３０日後よりも後の日が決済日であるとする。また、ユーザは、オンラインカード決済を指定して、予約の操作を行う。すると、宿泊施設予約サーバ１は、指定されたクレジットカードの与信確認を行う（図２（１））。このとき、宿泊施設予約サーバ１は、与信を確認することができなかった場合には、ユーザに決済方法を変更させるように制御する。一方、宿泊施設予約サーバ１は、与信を確認することができた場合には、決済方法をオンラインカード決済として予約を受け付ける。
【００４３】
その後、決済日の３０日前となった日に、宿泊施設予約サーバ１は、予約時に指定されたクレジットカードの第１回再与信確認を行う（図２（２））。なお、第１回再与信確認の日は、決済日から与信期間の日数前の日に限られるものではない。宿泊施設予約サーバ１は、決済日から与信期間の日数前の日以降の何れかの日に再与信確認を行えばよい。チェックイン日を基準とする場合においては、宿泊施設予約サーバ１は、チェックイン日から与信期間の日数前の日以降の何れかの日に第１回再与信確認を行えばよい。何れの場合も、宿泊料金の決済の安全性の観点から、宿泊施設予約サーバ１は、チェックイン日の前日までに第１回再与信確認を行ってもよい。
【００４４】
宿泊施設予約サーバ１は、第１回再与信確認において与信を確認することができた場合には、決済方法を変更しない。そして、ユーザが宿泊施設に宿泊した後、宿泊施設予約サーバ１は、チェックアウト日の翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する（図２（３））。なお、チェックイン日を基準とする場合、決済日よりも前に与信期間が経過する場合がある。具体的には、チェックイン日の３０日前の日から、決済日の３０日前の日の前日までに第１回再与信確認を行った場合には、決済日が与信期間に含まれない。この場合、宿泊施設予約サーバ１は、例えば、決済日の３０日前の日以降に与信確認を行い、与信を確認することができた状態で決済する。
【００４５】
一方、宿泊施設予約サーバ１は、第１回再与信確認において与信を確認することができなかった場合、この時点では決済方法を変更しないが、決済方法を変更することを示す情報を出力する。その理由は、ユーザが決済方法を自主的変更する機会をユーザに与えるためである。宿泊施設予約サーバ１は、決済方法を変更することを示す情報として、例えば、決済方法変更予告メールを、予約したユーザ宛てに送信する。決済方法変更予告メールは、決済方法がオンラインカード決済から現地決済に変更されることを予告する電子メールである。ユーザ端末４により決済方法変更予告メールを受信したユーザは、例えば、オンラインカード決済に利用するクレジットカードを、予約時に指定したクレジットカードとは異なるクレジットカードに変更することができる。これにより、ユーザは、決済方法をオンラインカード決済のままにしておくことができる。宿泊施設予約サーバ１は、ユーザが、クレジットカードの変更を要求した場合、新しく指定されたクレジットカードで与信を確認する。そして、宿泊施設予約サーバ１は、与信を確認することができた場合には、クレジットカードの変更を受け付ける。
【００４６】
宿泊施設予約サーバ１は、第１回再与信確認において与信を確認することができず、且つ、クレジットカードの変更が行われなかった場合には、チェックイン日の１１日前となった日に、予約時に指定されたクレジットカードで更に与信確認を行う（図２（４））。第１回再与信確認において与信を確認することができなかった後の再与信確認を、「ＮＧ時再与信確認」という。宿泊施設予約サーバ１がＮＧ時再与信確認を行う理由は、第１回再与信確認の時点で宿泊料金をクレジットカードで決済する信用がなくなっていたとしても、その後信用が回復する場合があるからである。例えば、月に１回、過去の１ヶ月の間に決済の処理が行われた与信枠がクリアされる日がある。与信枠がクリアされる日を「与信枠クリア日」という。実際には、例えば、与信枠クリア日の前日から与信枠クリア日になるタイミングで、与信枠がクリアされる。与信枠がクリアされると、与信枠クリア日に、クレジットカードの利用可能額が増加する。与信枠クリア日は、例えば、クレジットカード会社ごとに定められている。例えば、与信枠クリア日は、月初の日である。また例えば、与信枠クリア日は、引き落とし日である。引き落とし日は、ユーザの口座からクレジットカードの利用料金が引き落とされる日である。また、与信枠クリア日ではなくとも、与信枠が解除される場合もある。例えば、確保されていた与信枠に対応する取り引きが取り消された場合である。
【００４７】
チェックイン日の１１日前の日は、ＮＧ時再与信確認を行う日としてのデフォルトの日である。宿泊施設予約サーバ１は、１ヶ月の間のうち、宿泊料金を決済する信用が回復する蓋然性が高い日を推定する。この日を、「信用回復日」という。信用回復日は、与信枠クリア日であることもある。宿泊施設予約サーバ１は、推定した信用回復日に、ＮＧ時再与信確認を行う。具体的に、宿泊施設予約サーバ１は、第１回再与信確認において与信を確認することができなかった日と、ＮＧ時再与信確認において与信を確認することができた日と、を履歴として記録する。第１回再与信確認の日の翌日からＮＧ時再与信確認の日までの間に、宿泊料金を決済する信用が回復した日が存在する。そこで、宿泊施設予約サーバ１は、この間に含まれる日の中から、信用回復日を推定する。例えば、宿泊施設予約サーバ１は、第１回再与信確認の日とＮＧ時再与信確認の日とのちょうど中間の日を、信用回復日と推定してもよい。宿泊施設予約サーバ１は、宿泊料金を決済する信用が回復する蓋然性が高い日を推定し、推定した日にＮＧ時再与信確認を行ことにより、与信を確認することができる確率を高めることができる。また、信用が回復する蓋然性が高い日を推定することにより、クレジットカード会社が与信枠クリア日を公表していない場合にも有効である。
【００４８】
宿泊施設予約サーバ１は、ＮＧ時再与信確認において与信を確認することができた場合には、決済方法を変更しない。また、宿泊施設予約サーバ１は、決済方法が予約時に指定されたクレジットカードでのオンラインカード決済に維持されたことを示す情報を出力する。この情報として、宿泊施設予約サーバ１は、例えば、オンラインカード決済通知メールを、予約したユーザ宛てに送信する。オンラインカード決済通知メールは、決済方法がオンラインカード決済から現地決済に変更されないことを通知する電子メールである。そして、宿泊施設予約サーバ１は、チェックアウト日の翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する（図２（５））。
【００４９】
一方、宿泊施設予約サーバ１は、ＮＧ時再与信確認において与信を確認することができなかった場合において、チェックイン日の１１日前までにユーザが決済方法を自主的に変更しなかった場合には、チェックイン日の１０日前となった日に、決済方法を現地決済に変更する（図２（６））。チェックインの直前になっても与信を確認することができないと、ユーザが宿泊料金を決済可能であるかという不安を、宿泊施設の提供者に与える場合がある。宿泊施設予約サーバ１は、このような不安を与えないために、チェックイン日から予め設定された日前に、決済方法をオンラインカード決済から現地決済に変更する。また、宿泊施設予約サーバ１は、決済方法を変更することを示す情報を出力する。この情報として、宿泊施設予約サーバ１は、例えば、現地決済通知メールを、予約したユーザ宛てに送信する。現地決済通知メールは、決済方法がオンラインカード決済から現地決済に変更されたことを通知する電子メールである。その後、ユーザが宿泊施設に宿泊してチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する（図２（７））。なお、ユーザ端末４により現地決済通知メールを受信したユーザは、例えば、予約時に指定したクレジットカードとは異なるクレジットカードを指定して、決済方法をオンラインカード決済に変更することができる。
【００５０】
なお、宿泊施設予約サーバ１は、チェックイン日の前日に、宿泊施設を予約したユーザ宛てに予約内容を記載した電子メールを送信する。そのため、宿泊施設予約サーバ１は、オンラインカード決済通知メールや現地決済通知メールを送信する代わりに、予約内容を記載する電子メールに、確定した決済方法を記載してもよい。
【００５１】
また、決済方法が現地決済に変更される日は、チェックイン日の１０日前以外の日であってもよい。また、宿泊施設予約サーバ１は、第１回再与信確認で与信を確認することができなかった場合、その時点で決済方法を現地決済に変更してもよい。そして、宿泊施設予約サーバ１は、ＮＧ時再与信確認で与信を確認することができた場合、決済方法をオンラインカード決済に変更してもよい。
【００５２】
また、宿泊施設予約サーバ１は、信用回復日を推定せずに、チェックイン日から予め設定された日数前に、ＮＧ時再与信確認を行ってもよい。また、ＮＧ時再与信確認のデフォルトの日は、チェックイン日の１１日前に限られるものではない。例えば、宿泊施設予約サーバ１は、与信枠クリア日に、ＮＧ時再与信確認を行ってもよい。また、宿泊料金の決済の安全性の観点から、宿泊施設予約サーバ１は、チェックイン日の前日までにＮＧ時再与信確認を行ってもよい。また、宿泊施設予約サーバ１は、ＮＧ時再与信確認を行わなくてもよい。
【００５３】
ところで、予約時にユーザが指定したチェックイン日及びチェックアウト日によっては、宿泊施設の利用日数が、与信期間の日数以上となる場合がある。宿泊施設の利用日数は、宿泊日数よりも１日多い日数である。この場合において、決済日から与信期間日数前の日以降に第１回再与信確認を行うと仮定した場合、宿泊施設予約サーバ１はチェックイン日以降に第１回再与信確認を行うことになる。しかしながら、上述した宿泊料金の決済の安全性の観点から、宿泊施設予約サーバ１は、チェックイン日の前日までに再与信確認を行う。具体的に、宿泊施設予約サーバ１は、チェックイン日から与信期間の日数前の日以降で、極力予約日に近い日に第１回再与信確認を行う。その理由は、チェックイン日を与信期間に含ませる与信確認を早めに行うためである。その後、宿泊施設予約サーバ１は、チェックイン日から与信期間の日数前の日以降で、極力チェックイン日に近い日に更に再与信確認を行う。この再与信確認を、「チェックイン直前再与信確認」という。チェックイン直前再与信確認を行う理由は、ユーザが宿泊施設を利用している期間のうち極力長い期間、宿泊料金を決済する信用が確保された状態を維持するためである。そして、宿泊施設予約サーバ１は、決済日から与信期間日数前の日以降に、更に再与信確認を行う。この再与信確認を、「チェックイン後再与信確認」という。
【００５４】
以下に、概要を説明する。図３及び図４は、宿泊施設の利用日数が与信期間の日数以上である場合の予約から決済までの処理の流れを示す図である。なお、図３及び図４は、与信期間の日数が３０日である場合の例を示す。
【００５５】
図３に示すように、ユーザが、チェックイン日及びチェックアウト日を指定する。その結果、利用日数が３０日以上であるとする。また、ユーザは、オンラインカード決済を指定して、予約の操作を行う。宿泊施設予約サーバ１は、図２（１）と同様に、与信確認を行い（図３（１））、与信を確認することができた場合には、決済方法をオンラインカード決済として予約を受け付ける。
【００５６】
その後、チェックイン日の３０日前となった日に、宿泊施設予約サーバ１は、予約時に指定されたクレジットカードの第１回再与信確認を行う（図３（２））。なお、第１回再与信確認の日は、チェックイン日の３０日前に限られるものではない。宿泊施設予約サーバ１は、チェックイン日が与信期間に含まれるように、第１回再与信確認を行えばよい。
【００５７】
宿泊施設予約サーバ１は、与信を確認することができた場合には、決済方法を変更しない。一方、宿泊施設予約サーバ１は、与信を確認することができなかった場合には、決済方法変更予告メールを送信する。その後、宿泊施設予約サーバ１は、チェックイン日の１１日前となった日に、ＮＧ時再与信確認を行う（図３（３））。宿泊施設予約サーバ１は、ＮＧ時再与信確認において与信を確認することができた場合には、決済方法を変更しない。一方、宿泊施設予約サーバ１は、ＮＧ時再与信確認において与信を確認することができなかった場合には、チェックイン日の１０日前となった日に、決済方法を現地決済に変更する（図３（４））。決済方法が現地決済に変更された後、図４に示すように、ユーザが宿泊施設に宿泊してチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する（図４（５））。ここまで説明した処理は、第１回再与信確認を行う日を除いて、図２に示した処理と基本的に同様である。
【００５８】
第１回再与信確認において与信を確認することができた場合、または、ＮＧ時再与信確認において与信を確認することができた場合、宿泊施設予約サーバ１は、チェックイン日の３日前となった日に、予約時に指定されたクレジットカードのチェックイン直前再与信確認を行う（図４（６））。宿泊施設予約サーバ１は、チェックイン直前再与信確認において与信を確認することができた場合には、決済方法を変更しない。一方、宿泊施設予約サーバ１は、チェックイン直前再与信確認において与信を確認することができなかった場合には、この時点で決済方法を現地決済に変更する。その後、ユーザがチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する（図４（７））。
【００５９】
チェックイン直前再与信確認において与信を確認することができた場合には、チェックイン日以降、決済日の３０日前となった日に、宿泊施設予約サーバ１は、予約時に指定されたクレジットカードのチェックイン後再与信確認を行う（図４（８））。なお、チェックイン後再与信確認の日は、決済日から与信期間の日数前の日に限られるものではない。宿泊施設予約サーバ１は、決済日から与信期間の日数前の日以降の何れかの日に再与信確認を行えばよい。
【００６０】
宿泊施設予約サーバ１は、チェックイン後再与信確認において与信を確認することができた場合には、決済方法を変更しない。そして、ユーザが宿泊施設に宿泊した後、宿泊施設予約サーバ１は、チェックアウト日の翌日に、予約時に指定されたクレジットカードで宿泊料金を決済する（図４（９））。一方、宿泊施設予約サーバ１は、チェックイン後再与信確認において与信を確認することができなかった場合には、決済方法を現地決済に変更する。その後、ユーザがチェックアウトするときに、ユーザが、宿泊施設で宿泊料金を決済する（図４（１０））。
【００６１】
なお、宿泊施設予約サーバ１は、宿泊施設の利用日数が与信期間の日数以上である場合、チェックイン日までの日数が与信期間の日数となった日からチェックイン日の前日までの何れかの日に、第１回再与信確認を行い、チェックイン直前再与信確認を行わなくてもよい。この場合、宿泊施設予約サーバ１は、予約日に近い日に第１回再与信確認を行ってもよいし、チェックイン日に近い日に第１回再与信確認を行ってもよい。また、宿泊施設予約サーバ１は、チェックイン日の１０日前以降に第１回再与信確認を行った場合には、チェックイン日の１０日前となった日に決済方法を現地決済に変更する理由により、ＮＧ時再与信確認を行わなくてもよい。
【００６２】
ユーザが実際に宿泊施設を利用した際、予約時に確定した宿泊料金とは別に、料金が発生する場合がある。例えば、利用料金が予約時の宿泊料金に含まれていないサービスをユーザが利用した場合や、宿泊施設で何らかの物をユーザが購入した場合である。宿泊施設の利用によって宿泊料金とは別に発生する料金を、「オプション料金」という。ユーザは、オンラインカード決済を利用する場合、オプション料金と宿泊料金を含む利用料金をオンラインカード決済で決済することができる。具体的には、例えば、チェックアウトの際に、宿泊施設の提供者がオプション料金を精算する。そして、提供者は、宿泊施設端末３を操作して、オプション料金の登録を要求する。すると、宿泊施設予約サーバ１は、オプション料金について与信確認を行う。このとき、宿泊施設予約サーバ１は、与信を確認することができた場合には、チェックアウト日の翌日に、オプション料金を含めて宿泊料金を決済する。一方、宿泊施設予約サーバ１が与信を確認することができなかった場合には、例えば、その場でユーザがオプション料金の決済の手続を行う。この場合でも、宿泊料金は、オンラインカード決済で決済される。
【００６３】
［３．宿泊施設予約サーバの構成］
次に、宿泊施設予約サーバ１の構成について、図５及び図６を用いて説明する。
【００６４】
図５は、本実施形態に係る宿泊施設予約サーバ１の概要構成の一例を示すブロック図である。図５に示すように、宿泊施設予約サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。
【００６５】
通信部１１は、ネットワークＮＷに接続して、ユーザ端末４等との通信状態を制御するようになっている。
【００６６】
記憶部１２は、例えば、ハードディスクドライブ等により構成されている。この記憶部１２には、会員情報ＤＢ１２ａ、宿泊施設情報ＤＢ１２ｂ、予約情報ＤＢ１２ｃ、再与信確認履歴ＤＢ１２ｄ等のデータベースが構築されている。「ＤＢ」は、データベースの略語である。なお、記憶部１２は、本発明における記憶手段及び確認日記憶手段の一例である。
【００６７】
図６（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図である。会員情報ＤＢ１２ａには、情報処理システムＳに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス、登録クレジットカード情報等が、ユーザごとに対応付けて登録される。ユーザＩＤは、ユーザの識別情報である。登録クレジットカード情報は、ユーザにより登録されたクレジットカードのカード情報である。登録クレジットカード情報には、例えば、クレジットカード会社情報、カード番号、有効期限、名義人の名称等の情報が設定される。クレジットカード会社情報は、クレジットカード会社を識別する情報である。ユーザは、予めカード情報を登録しておくことにより、予約のたびにカード情報を入力しなくてもよい。
【００６８】
図６（ｂ）は、宿泊施設情報ＤＢ１２ｂに登録される内容の一例を示す図である。宿泊施設情報ＤＢ１２ｂには、宿泊施設に関する宿泊施設情報が登録される。具体的に、宿泊施設情報ＤＢ１２ｂには、施設ＩＤ、宿泊施設名、郵便番号、住所、電話番号、ＦＡＸ番号、電子メールアドレス、プラン情報等の宿泊施設の属性が、宿泊施設ごとに対応付けて登録される。施設ＩＤは、宿泊施設の識別情報である。プラン情報は、宿泊施設が提供する宿泊プランに関する情報である。宿泊プランは、例えば、宿泊施設の提供者により企画された宿泊サービスである。プラン情報には、例えば、プランＩＤ、宿泊プラン名、客室タイプＩＤ、宿泊プランの内容、１泊の宿泊料金の説明等の宿泊プランの属性が宿泊プランごとに設定されている。プランＩＤは、宿泊プランの識別情報である。客室タイプＩＤは、客室のタイプを示す識別情報である。
【００６９】
図６（ｃ）は、予約情報ＤＢ１２ｃに登録される内容の一例を示す図である。予約情報ＤＢ１２ｃには、受け付けられた予約に関する予約情報が登録される。具体的に、予約情報ＤＢ１２ｃには、予約番号、予約日、ユーザＩＤ、施設ＩＤ、プランＩＤ、客室タイプ、チェックイン日、チェックアウト日、利用人数、宿泊料金、決済方法情報、オンラインカード決済管理情報等の情報が予約ごとに対応付けて登録される。予約番号は、予約の識別情報である。ユーザＩＤは、予約したユーザを示す。施設ＩＤは、予約された宿泊施設を示す。プランＩＤ及び客室タイプＩＤは、予約された宿泊プラン及び客室タイプを示す。宿泊料金は、予約時に確定している利用料金である。宿泊料金は、宿泊プラン、客室タイプ、宿泊日数及び利用人数に応じて決定される。決済方法情報は、決済方法を示す情報である。決済方法情報には、「現地決済」または「オンラインカード決済」の何れかが設定される。
【００７０】
オンラインカード決済管理情報は、決済方法がオンラインカード決済である場合に登録される。オンラインカード決済管理情報には、クレジットカード情報、与信確認結果、宿泊料金承認番号、オプション料金決済フラグ、オプション料金、オプション料金承認番号、再与信確認フラグ、再与信確認日及び再与信確認種別が設定される。クレジットカード情報は、ユーザにより指定されたクレジットカードのカード情報である。与信確認結果は、最新の与信確認における確認結果を示す。与信確認結果にＯＫが設定されている場合、与信を確認することができたことを示す。与信確認結果にＮＧが設定されている場合、与信を確認することができなかったことを示す。宿泊料金承認番号は、宿泊料金の決済についてクレジットカードの与信が承認された場合に、決済サーバ２から宿泊施設予約サーバ１に送信される承認番号である。承認番号は、与信が承認された取り引きの識別情報である。オプション料金決済フラグは、オプション料金をオンラインカード決済で決済するか否かを示す情報である。オプション料金決済フラグがＯＮに設定されている場合、オプション料金はオンラインカード決済で決済されることを示す。オプション料金決済フラグがＯＦＦに設定されている場合、オプション料金はオンラインカード決済では決済されないことを示す。オプション料金承認番号は、オプション料金の決済についてクレジットカードの与信が承認された場合に、決済サーバ２から宿泊施設予約サーバ１に送信される承認番号である。再与信確認フラグは、再与信確認が必要であるか否かを示す情報である。再与信確認フラグがＯＮに設定されている場合、再与信確認が必要であることを示す。再与信確認フラグがＯＦＦに設定されている場合、再与信確認が不要であることを示す。再与信確認日は、次の再与信確認が行われる日を示す。再与信確認種別は、再与信確認日に行われる再与信確認の種別を示す。再与信確認種別には、「第１回」、「ＮＧ時」、「チェックイン直前」または「チェックイン後」の何れかが設定される。「第１回」は、第１回再与信確認を示す。「ＮＧ時」は、ＮＧ時再与信確認を示す。「チェックイン直前」は、チェックイン直前再与信確認を示す。「チェックイン後」は、チェックイン後再与信確認を示す。
【００７１】
図６（ｄ）は、再与信確認履歴ＤＢ１２ｄに登録される内容の一例を示す図である。再与信確認履歴ＤＢ１２ｄには、第１回再与信確認において与信を確認することができなかった日を含む再与信確認履歴と、ＮＧ時再与信確認において与信を確認することができた日を含む再与信確認履歴とが登録される。具体的に、再与信確認履歴ＤＢ１２ｄには、予約番号、再与信確認日、再与信確認種別及びクレジットカード会社情報が対応付けて登録される。予約番号は、再与信確認が行われた予約を示す。再与信確認日は、与信を確認することができなかった第１回再与信確認の日、または、与信を確認することができたＮＧ時再与信確認の日の何れかである。再与信確認種別は、行われた再与信確認の種別である。再与信確認種別には、「第１回」または「ＮＧ時」の何れかが設定される。クレジットカード会社情報は、再与信確認が行われたクレジットカードの発行元のクレジットカード会社を示す。
【００７２】
次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、Ｗｅｂページを表示するためのＨＴＭＬ（HyperText Markup Language）文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。
【００７３】
また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、宿泊施設予約処理プログラム等の各種プログラムが記憶されている。宿泊施設予約処理プログラムは、宿泊施設の検索、宿泊施設の予約、宿泊料金の与信確認や決済の処理を実行するためのプログラムである。宿泊施設予約処理プログラムは、本発明における情報処理プログラムの一例である。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【００７４】
入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。
【００７５】
システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。そして、システム制御部１４は、ＣＰＵ１４ａが、各種プログラムを読み出し実行することにより、本発明における第１確認手段、予約手段、第２確認手段、出力手段、第３確認手段、第４確認手段、第５確認手段、記憶制御手段、推定手段、判定手段及び決済手段として機能するようになっている。
【００７６】
なお、宿泊施設予約サーバ１が、複数のサーバ装置で構成されてもよい。例えば、宿泊施設の検索を行うサーバ装置、宿泊施設の予約や与信確認の処理を行うサーバ装置、ユーザ端末４からのリクエストに応じてＷｅｂページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されてもよい。
【００７７】
［４．情報処理システムの動作］
次に、情報処理システムＳの動作について、図７乃至図１２を用いて説明する。
【００７８】
図７は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の予約処理における処理例を示すフローチャートである。
【００７９】
例えば、ユーザが宿泊施設サイトにおいて宿泊施設を検索し、所望の宿泊施設、宿泊プラン及び客室タイプを選択する。次いで、ユーザは、チェックイン日、チェックアウト日及び利用人数を選択する。すると、ユーザ端末４の画面には、決済方法指定ページが表示される。決済方法指定ページは、決済方法を指定するためのＷｅｂページである。ここで、ユーザは、決済方法としてオンラインカード決済を選択した場合、決済に利用するクレジットカードのカード情報を入力する。このとき、ユーザは、会員情報に情報が登録されているクレジットカードを指定することができる。この場合、ユーザは、カード情報を入力しない。ユーザは、必要な選択及び入力を行った後、予約を要求するためのボタンを選択する。すると、ユーザ端末４は、予約リクエストを宿泊施設予約サーバ１へ送信する。予約リクエストは、ユーザＩＤ、ユーザにより選択された宿泊施設、宿泊プラン及び客室タイプに対応する施設ＩＤ、プランＩＤ及び客室ＩＤと、チェックイン日、チェックアウト日及び利用人数とを含む。また、予約リクエストは、会員情報に情報が登録されているクレジットカードを利用するか否かを示す情報と、ユーザにより入力されたカード情報とを含む。予約処理は、宿泊施設予約サーバ１が予約リクエストを受信したときに開始される。
【００８０】
図７に示すように、システム制御部１４は、ユーザにより選択された決済方法がオンラインカード決済であるか否かを判定する（ステップＳ１）。このとき、システム制御部１４は、決済方法がオンラインカード決済ではないと判定した場合には（ステップＳ１：ＮＯ）、決済方法情報に「現地決済」を設定する（ステップＳ２）。次いで、システム制御部１４は、予約情報を登録する（ステップＳ３）。具体的に、システム制御部１４は、新しい予約番号を生成する。次いで、システム制御部１４は、予約番号、予約リクエストに含まれる情報、設定を行った決済方法情報等を含む予約情報を生成する。次いで、システム制御部１４は、生成した予約情報を予約情報ＤＢ１２ｃに登録する。システム制御部１４は、ステップＳ３の処理を終えると、予約処理を終了させる。
【００８１】
一方、システム制御部１４は、決済方法がオンラインカード決済であると判定した場合には（ステップＳ１：ＹＥＳ）、第１確認手段として、ユーザにより指定されたクレジットカードのカード情報に基づいて、与信を確認する（ステップＳ４）。具体的に、システム制御部１４は、予約リクエストに含まれる施設ＩＤ、プランＩＤ、客室タイプＩＤ及び利用人数に基づいて、宿泊料金を計算する。また、システム制御部１４は、ユーザが指定したクレジットカードのカード情報を取得する。ユーザがカード情報を入力した場合には、予約情報リクエストからカード情報を取得する。一方、システム制御部１４は、ユーザが、登録されているクレジットカードを指定した場合には、会員情報ＤＢ１２ａから、予約を要求したユーザのユーザＩＤに対応する会員情報を検索する。そして、システム制御部１４は、検索した会員情報から登録クレジットカード情報を取得する。システム制御部１４は、カード情報を取得すると、与信確認リクエストを決済サーバ２に送信する。与信確認リクエストは、取得されたカード情報、利用額等を含む。システム制御部１４は、利用額として宿泊料金を設定する。
【００８２】
決済サーバ２は、与信確認リクエストを受信すると、与信を承認するか否かを判定する。具体的に、決済サーバ２は、与信確認リクエストに含まれるカード情報が、有効なクレジットカードのカード情報であるか否かを判定する。また、決済サーバ２は、カード情報に基づいて、クレジットカードの有効期限が切れているか否かを判定する。また、決済サーバ２は、現時点でのクレジットカードの利用可能額が、与信確認リクエストに含まれる利用額以上であるか否かを判定する。
【００８３】
決済サーバ２は、カード情報が有効なクレジットカードのカード情報であり、有効期限が切れておらず、且つ、利用可能額が利用額以上である場合、与信を承認する。この場合、決済サーバ２は、新たな承認番号を発行する。また、決済サーバ２は、宿泊料金に相当する与信枠を確保する。例えば、決済サーバ２は、承認番号、宿泊料金、カード情報等を対応付けて、決済サーバ２が備えるデータベースに登録する。また、決済サーバ２は、カード情報に対応する利用可能額を更新する。そして、決済サーバ２は、承認番号を含む与信確認応答を宿泊施設予約サーバ１に送信する。
【００８４】
一方、決済サーバ２は、カード情報が有効なクレジットカードのカード情報ではない場合、有効期限が切れている場合、または、利用可能額が利用額未満である場合、与信を承認しない。この場合、決済サーバ２は、エラー種別を含む与信確認応答を宿泊施設予約サーバ１に送信する。この場合、与信確認応答は承認番号を含まない。エラー種別は、与信を承認することができない理由を示す情報である。エラー種別としては、例えば、「カード無効」、「期限切れ」、「限度額オーバー」等がある。「カード無効」は、カード情報が無効であることを示す。「期限切れ」は、クレジットカードの有効期限が切れていることを示す。「限度額オーバー」は、利用額が利用可能額を超えていることを示す。
【００８５】
システム制御部１４は、決済サーバ２から与信確認応答を受信すると、与信を確認することができたか否かを判定する（ステップＳ５）。このとき、システム制御部１４は、承認番号を含まない与信確認応答を受信した場合には、与信を確認することができなかったと判定する（ステップＳ５：ＮＯ）。この場合、システム制御部１４は、決済方法指定ページを、予約リクエストの送信元のユーザ端末４へ送信する（ステップＳ６）。システム制御部１４は、ステップＳ６の処理を終えると、予約処理を終了させる。決済方法指定ページにおいて、ユーザは、決済方法を再度指定する。そして、ユーザが、予約を要求するためのボタンを選択すると、ユーザ端末４は、予約リクエストを宿泊施設予約サーバ１へ送信する。
【００８６】
ステップＳ５において、システム制御部１４は、決済サーバ２からから承認番号を含む与信確認応答を受信した場合には、与信を確認することができたと判定する（ステップＳ５：ＹＥＳ）。この場合、システム制御部１４は、決済方法情報に「オンラインカード決済」を設定する。また、システム制御部１４は、クレジットカード情報に、ステップＳ４において取得したカード情報を設定する。また、システム制御部１４は、与信確認結果にＯＫを設定する。また、また、システム制御部１４は、宿泊料金承認番号に、与信確認応答に含まれる承認番号を設定する。また、システム制御部１４は、オプション料金決済フラグをＯＦＦに設定する（ステップＳ７）。次いで、システム制御部１４は、予約リクエストに含まれるチェックアウト日の翌日を、決済日として設定する（ステップＳ８）。
【００８７】
次いで、システム制御部１４は、今日から決済日までの日数が与信日数を超えるか否かを判定する（ステップＳ９）。このとき、システム制御部１４は、今日から決済日までの日数が与信日数を超えないと判定した場合には（ステップＳ９：ＮＯ）、再与信確認フラグをＯＦＦに設定する（ステップＳ１０）。次いで、システム制御部１４は、ステップＳ１５に移行する。
【００８８】
一方、システム制御部１４は、今日から決済日までの日数が与信日数を超えると判定した場合には（ステップＳ９：ＹＥＳ）、再与信確認フラグをＯＮに設定する。また、システム制御部１４は、再与信確認種別に「第１回」を設定する（ステップＳ１１）。次いで、システム制御部１４は、予約リクエストに含まれるチェックイン日及びチェックアウト日に基づいて、宿泊施設の利用日数を計算する。そして、システム制御部１４は、利用日数が与信日数未満であるか否かを判定する（ステップＳ１２）。このとき、システム制御部１４は、利用日数が与信日数未満であると判定した場合には（ステップＳ１２：ＹＥＳ）、再与信確認日に、決済日から与信日数前の日を設定する。（ステップＳ１３）。次いで、システム制御部１４は、ステップＳ１５に移行する。
【００８９】
一方、システム制御部１４は、利用日数が与信日数以上であると判定した場合には（ステップＳ１２：ＮＯ）、再与信確認日に、チェックイン日から与信日数前の日を設定する。（ステップＳ１４）。次いで、システム制御部１４は、ステップＳ１５に移行する。
【００９０】
ステップＳ１５において、システム制御部１４は、予約手段として、ユーザにより指定されたクレジットカードのカード情報を含む予約情報を登録する。具体的に、システム制御部１４は、新しい予約番号、予約リクエストに含まれる情報、設定を行った決済方法情報、クレジットカード情報、与信確認結果、宿泊料金承認番号、オプション料金決済フラグ、再与信確認フラグ、再与信確認日、再与信確認種別等を含む予約情報を生成する。次いで、システム制御部１４は、生成した予約情報を予約情報ＤＢ１２ｃに登録する。システム制御部１４は、予約情報を登録することにより、要求された予約を受け付ける。システム制御部１４は、ステップＳ１５の処理を終えると、予約処理を終了させる。
【００９１】
図８及び図９は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の再与信確認処理における処理例を示すフローチャートである。宿泊施設予約サーバ１は、再与信確認処理と、後述する決済方法変更処理及び決済処理とを、１日に１回実行する。宿泊施設予約サーバ１は、再与信確認処理、決済方法変更処理及び決済処理を連続して実行してもよい。
【００９２】
図８に示すように、システム制御部１４は、予約情報ＤＢ１２ｃから、再与信確認フラグがＯＮに設定されている予約情報のうち、再与信確認日が今日である予約情報を検索する（ステップＳ３１）。次いで、システム制御部１４は、検索した予約情報のうち１つを選択する（ステップＳ３２）。次いで、システム制御部１４は、選択した予約情報が対応する予約について、予約時の与信確認により確保された与信を取り消す（ステップＳ３３）。この処理を行う理由は、１つの予約に対して与信枠が複数確保されることを防止するためである。具体的に、システム制御部１４は、選択した予約情報から宿泊料金承認番号を取得する。次いで、システム制御部１４は、取得した宿泊料金承認番号を承認番号として含む与信取消リクエストを決済サーバ２に送信する。決済サーバ２は、与信取消リクエストを受信すると、与信取消リクエストに含まれる承認番号に対応する与信枠を解除する。なお、システム制御部１４は、前回与信確認を行った日から与信期間が経過している場合には、与信の取り消しを実行しなくてもよい。
【００９３】
次いで、システム制御部１４は、第２〜第５確認手段として、選択した予約情報に含まれるクレジットカード情報に基づいて、与信を確認する（ステップＳ３４）。この処理の内容は、図７に示す予約処理のステップＳ４の処理内容と同様である。ただし、システム制御部１４は、選択した予約情報に含まれるクレジットカード情報を、与信確認リクエストに設定する。次いで、システム制御部１４は、与信を確認することができたか否かを判定する（ステップＳ３５）。このとき、システム制御部１４は、与信を確認することができなかったと判定した場合には（ステップＳ３５：ＮＯ）、ステップＳ５１に移行する。一方、システム制御部１４は、与信を確認することができたと判定した場合には（ステップＳ３５：ＹＥＳ）、ステップＳ３４において決済サーバ２から受信した与信確認応答に含まれる承認番号で、選択した予約情報に含まれる宿泊料金承認番号を上書きする。
【００９４】
次いで、システム制御部１４は、選択した予約情報に含まれる再与信確認種別が「第１回」であるか否かを判定する（ステップＳ３６）。このとき、システム制御部１４は、再与信確認種別が「第１回」ではないと判定した場合には（ステップＳ３６：ＮＯ）、ステップＳ４１に移行する。一方、システム制御部１４は、再与信確認種別が「第１回」であると判定した場合には（ステップＳ３６：ＹＥＳ）、選択した予約情報に含まれるチェックイン日及びチェックアウト日に基づいて、宿泊施設の利用日数を計算する。そして、システム制御部１４は、利用日数が与信日数未満であるか否かを判定する（ステップＳ３７）。このとき、システム制御部１４は、利用日数が与信日数未満であると判定した場合には（ステップＳ３７：ＹＥＳ）、ステップＳ４６に移行する。
【００９５】
一方、システム制御部１４は、利用日数が与信日数以上であると判定した場合には（ステップＳ３７：ＮＯ）、今日が、選択した予約情報に含まれるチェックイン日から４日以上前であるか否かを判定する（ステップＳ３８）。このとき、システム制御部１４は、今日がチェックイン日から４日以上前であると判定した場合には（ステップＳ３８：ＹＥＳ）、選択した予約情報に含まれる再与信確認日に、チェックイン日の３日前の日を設定する。また、システム制御部１４は、選択した予約情報に含まれる再与信確認種別を「チェックイン直前」に変更する（ステップＳ３９）。次いで、システム制御部１４は、ステップＳ４６に移行する。
【００９６】
一方、システム制御部１４は、今日がチェックイン日から３日以下であると判定した場合には（ステップＳ３８：ＮＯ）、選択した予約情報に含まれる再与信確認日に、決済日から与信日数前の日を設定する。また、システム制御部１４は、選択した予約情報に含まれる再与信確認種別を「チェックイン後」に変更する（ステップＳ４０）。次いで、システム制御部１４は、ステップＳ４６に移行する。つまり、システム制御部１４は、ＮＧ時再与信確認ではなく、チェックイン後再与信確認を行うように設定する。その理由は、チェックイン日から３日前以降に第１回再与信確認が行われた場合には、第１回再与信確認によって、チェックイン直前再与信確認の目的が果たされているからである。
【００９７】
ステップＳ４１において、システム制御部１４は、選択した予約情報に含まれる再与信確認種別が「ＮＧ時」であるか否かを判定する。このとき、システム制御部１４は、再与信確認種別が「ＮＧ時」ではないと判定した場合には（ステップＳ４１：ＮＯ）、ステップＳ４５に移行する。一方、システム制御部１４は、再与信確認種別が「ＮＧ時」であると判定した場合には（ステップＳ４１：ＹＥＳ）、選択した予約情報に含まれる決済方法情報に、「オンラインカード決済」を設定する。また、システム制御部１４は、選択した予約情報に含まれる与信確認結果にＯＫを設定する（ステップＳ４２）。
【００９８】
次いで、システム制御部１４は、出力手段として、オンラインカード決済通知メールを送信する（ステップＳ４３）。具体的に、システム制御部１４は、選択した予約情報に含まれるユーザＩＤに対応する会員情報を、会員情報ＤＢ１２ａから検索する。次いで、システム制御部１４は、検索した会員情報からメールアドレスを取得する。次いで、システム制御部１４は、オンラインカード決済通知メールを生成する。このとき、システム制御部１４は、取得したメールアドレスを、オンラインカード決済通知メールの宛先に設定する。また、システム制御部１４は、オンラインカード決済通知メールの本文に、与信を確認することができたため、決済方法がオンラインカード決済から現地決済に変更されない旨の文章を設定する。そして、システム制御部１４は、生成したオンラインカード決済通知メールを送信する。
【００９９】
次いで、システム制御部１４は、記憶制御手段として、再与信確認履歴を登録する（ステップＳ４４）。具体的に、システム制御部１４は、選択した予約情報から予約番号、再与信確認日を取得する。また、システム制御部１４は、再与信確認種別に「ＮＧ時」を設定する。また、システム制御部１４は、選択した予約情報に含まれるクレジットカード情報から、クレジットカード会社情報を取得する。そして、システム制御部１４は、予約番号、再与信確認日、再与信確認種別及びクレジットカード会社情報を含む再与信確認履歴を、再与信確認履歴ＤＢ１２ｄに登録する。システム制御部１４は、ステップＳ４４の処理を終えると、ステップＳ３７に移行する。つまり、システム制御部１４は、利用日数が与信日数以上である場合には、チェックイン直前再与信確認またはチェックイン後再与信確認を行うように設定する。
【０１００】
ステップＳ４５において、システム制御部１４は、選択した予約情報に含まれる再与信確認種別が「チェックイン直前」であるか否かを判定する。このとき、システム制御部１４は、再与信確認種別が「チェックイン直前」であると判定した場合には（ステップＳ４５：ＹＥＳ）、ステップＳ４０に移行する。一方、システム制御部１４は、再与信確認種別が「チェックイン直前」ではないと判定した場合には（ステップＳ４５：ＮＯ）、ステップＳ４６に移行する。この場合、今回でチェックイン後再与信確認が行われたことになるので、システム制御部１４は、これ以上の再与信確認を行うようには設定しない。
【０１０１】
図９に示すように、ステップＳ５１においてシステム制御部１４は、選択した予約情報に含まれる与信確認結果にＮＧを設定する。次いで、システム制御部１４は、今日が、選択した予約情報に含まれるチェックイン日から１１日以上前であるか否かを判定する（ステップＳ５２）。このとき、システム制御部１４は、今日がチェックイン日から１１日以上前であると判定した場合には（ステップＳ５２：ＹＥＳ）、出力手段として、決済方法変更予告メールを送信する（ステップＳ５３）。具体的に、システム制御部１４は、決済方法変更予告メールを生成する。このとき、システム制御部１４は、ステップＳ４３の場合と同様に宛先を設定する。また、システム制御部１４は、決済方法変更予告メールの本文に、チェックイン日から１０日前になると決済方法がオンラインカード決済から現地決済に変更される旨の文章を設定する。そして、システム制御部１４は、生成した決済方法変更予告メールを送信する。システム制御部１４は、ステップＳ５３の処理を終えると、ステップＳ５６に移行する。
【０１０２】
一方、システム制御部１４は、今日がチェックイン日から１０日以内であると判定した場合には（ステップＳ５２：ＮＯ）、選択した予約情報に含まれる決済方法情報を「現地決済」に変更する（ステップＳ５４）。次いで、システム制御部１４は、出力手段として、現地決済通知メールを送信する（ステップＳ５５）。具体的に、システム制御部１４は、現地決済通知メールを生成する。このとき、システム制御部１４は、ステップＳ４３の場合と同様に宛先を設定する。また、システム制御部１４は、現地決済通知メールの本文に、決済方法がオンラインカード決済から現地決済に変更された旨の文章を設定する。そして、システム制御部１４は、生成した現地決済通知メールを送信する。システム制御部１４は、ステップＳ５５の処理を終えると、ステップＳ５６に移行する。なお、システム制御部１４は、予約された宿泊施設の提供者に対しても、現地決済通知メールを送信してもよい。
【０１０３】
ステップＳ５６において、システム制御部１４は、選択した予約情報に含まれる再与信確認種別が「第１回」であるか否かを判定する。このとき、システム制御部１４は、再与信確認種別が「第１回」ではないと判定した場合には（ステップＳ５６：ＮＯ）、ステップＳ４６に移行する。この場合、今回の再与信確認が第１回再与信確認ではないため、システム制御部１４は、ＮＧ時再与信確認を行うようには設定しない。一方、システム制御部１４は、再与信確認種別が「第１回」であると判定した場合には（ステップＳ５６：ＹＥＳ）、今日が、選択した予約情報に含まれるチェックイン日の２日以上前であるか否かを判定する（ステップＳ５７）。このとき、システム制御部１４は、今日がチェックイン日の前日以降であると判定した場合には（ステップＳ５７：ＮＯ）、ステップＳ４６に移行する。この場合、チェックイン日の前日までにＮＧ時再与信確認を行うことができる日がない。
【０１０４】
一方、システム制御部１４は、今日がチェックイン日の２日以上前であると判定した場合には（ステップＳ５７：ＹＥＳ）、ステップＳ３４において決済サーバ２から受信した与信確認応答に含まれるエラー種別を取得する。そして、システム制御部１４は、判定手段として、エラー種別が「限度額オーバー」であるか否かを判定する（ステップＳ５８）。このとき、システム制御部１４は、エラー種別が「限度額オーバー」ではないと判定した場合には（ステップＳ５８：ＮＯ）、ステップＳ４６に移行する。この場合、システム制御部１４は、ＮＧ時再与信確認を行うようには設定しない。エラー種別が「限度額オーバー」である場合にのみシステム制御部１４がＮＧ時再与信確認を行う理由は、ＮＧ時再与信確認によって与信を確認することができる蓋然性があるからである。一方、エラー種別が「カード無効」である場合、与信を確認することができる蓋然性は極めて低い。また、エラー種別が「期限切れ」である場合、ユーザがクレジットカードの有効期限を更新しない限り、与信を確認することはできないと考えられる。なお、システム制御部１４は、エラー種別の如何にかかわらず、ＮＧ時再与信確認を行うように設定を行ってもよい。
【０１０５】
一方、システム制御部１４は、エラー種別が「限度額オーバー」であると判定した場合には（ステップＳ５８：ＹＥＳ）、選択した予約情報に含まれる再与信確認種別を「ＮＧ時」に変更する（ステップＳ５９）。次いで、システム制御部１４は、記憶制御手段として、再与信確認履歴を登録する（ステップＳ６０）。この処理の内容は、ステップＳ４４の処理内容と基本的に同様である。ただし、システム制御部１４は、再与信確認種別に「第１回」を設定する。
【０１０６】
次いで、システム制御部１４は、選択した予約情報に含まれるクレジットカード情報から、クレジットカード会社情報を取得する。次いで、システム制御部１４は、取得したクレジットカード会社情報を含む再与信確認履歴を、再与信確認履歴ＤＢ１２ｄから検索する（ステップＳ６１）。
【０１０７】
次いで、システム制御部１４は、推定手段として、検索した再与信確認履歴に基づいて、取得したクレジットカード会社情報が示すクレジットカード会社が発行するクレジットカードの信用回復日を推定する（ステップＳ６２）。クレジットカード会社情報ごとに推定する理由は、クレジットカード会社情報ごとに、与信枠クリア日等の信用回復日が異なる場合があるからである。具体的に、システム制御部１４は、検索した再与信確認履歴から、同一の予約情報を含む再与信確認履歴の組を抽出する。同一の予約情報を含む再与信確認履歴の組は、再与信確認種別が「第１回」である再与信確認履歴と、再与信確認種別が「ＮＧ時」である再与信確認履歴の組み合わせである。システム制御部１４は、第１回再与信確認の日とＮＧ再与信確認の日との中間日を特定する。具体的に、システム制御部１４は、再与信確認種別が「第１回」である再与信確認履歴に含まれる再与信確認日から、再与信確認種別が「ＮＧ時」である再与信確認履歴に含まれる再与信確認日までの日数を算出する。次いで、システム制御部１４は、算出した日数の半分を、再与信確認種別が「第１回」である再与信確認履歴に含まれる再与信確認日に加算して、中間日を算出する。このとき、システム制御部１４は、算出された年月日のうち日のみを中間日とする。例えば、第１回再与信確認の日が２０１２年１月２５日であり、ＮＧ時再与信確認の日が２０１２年２月１０日であるとする。この場合、１月２５日から８日後の２０１２年２月２日が中間日となる。ただし、最終的な中間日は、２０１２年２月２日から２０１２年２月を除いた２日である。システム制御部１４は、抽出した再与信確認履歴の組ごとに、中間日の算出を行う。次いで、システム制御部１４は、１ヶ月間における中間日の分布に基づいて、中間日が集中する日を信用回復日として特定する。例えば、システム制御部１４は、中間日が最も多く分布する日を信用回復日としてもよい。また、システム制御部１４は、例えば、算出された中間日のうち所定割合以上の中間日が分布する日を信用回復日としてもよい。この場合、システム制御部１４は、複数の信用回復日を特定してもよい。また、システム制御部１４は、例えば、１ヶ月間を複数の期間に分割し、所定割合以上の中間日が分布する期間を特定してもよい。そして、システム制御部１４は、特定した期間の中央の日を信用回復日としてもよいし、特定した期間の開始日から終了日までのそれぞれを信用回復日としてもよい。
【０１０８】
システム制御部１４は、信用回復日を推定すると、明日から、選択した予約情報に含まれるチェックイン日の前日までに、推定した信用回復日があるか否かを判定する（ステップＳ６３）。このとき、システム制御部１４は、明日からチェックイン日の前日までの間に信用回復日があると判定した場合には（ステップＳ６３：ＹＥＳ）、選択した予約情報に含まれる再与信確認日に、推定した信用回復日を設定する（ステップＳ６４）。明日からチェックイン日の前日までの間に信用回復日が複数ある場合、システム制御部１４は、何れかの信用回復日を設定する。このとき、システム制御部１４は、信用が回復する蓋然性が最も高い信用回復日を設定してもよい。例えば、システム制御部１４は、明日からチェックイン日の前日までの間に含まれる信用回復日のうち中間日が最も多く分布する日を設定してもよい。システム制御部１４は、ステップＳ６４の処理を終えると、ステップＳ４６に移行する。
【０１０９】
一方、システム制御部１４は、明日からチェックイン日の前日までの間に信用回復日がないと判定した場合には（ステップＳ６３：ＮＯ）、今日が、予約情報に含まれるチェックイン日から１２日以上前であるか否かを判定する（ステップＳ６５）。このとき、システム制御部１４は、今日がチェックイン日から１２日以上前であると判定した場合には（ステップＳ６５：ＹＥＳ）、選択した予約情報に含まれる再与信確認日に、チェックイン日の１１日前の日を設定する（ステップＳ６６）。次いで、システム制御部１４は、ステップＳ４６に移行する。一方、システム制御部１４は、今日がチェックイン日から１１日以内であると判定した場合には（ステップＳ６５：ＮＯ）、選択した予約情報に含まれる再与信確認日に、今日とチェックイン日との中間日を設定する（ステップＳ６７）。次いで、システム制御部１４は、ステップＳ４６に移行する。なお、システム制御部１４は、チェックイン日から１１日以内に第１回再与信確認を行うことによって与信を確認することができなかった場合には、ＮＧ時再与信確認を行わなくてもよい。また、システム制御部１４は、明日からチェックイン日の前日までの間に、推定した信用回復日がなかった場合、ＮＧ時再与信確認を行わなくてもよい。
【０１１０】
ステップＳ４６において、システム制御部１４は、ステップＳ３１で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する。このとき、システム制御部１４は、まだ選択していない予約情報があると判定した場合には（ステップＳ４６：ＹＥＳ）、まだ選択していない予約情報のうち１つを選択する（ステップＳ４７）。次いで、システム制御部１４は、ステップＳ３３に移行する。システム制御部１４は、ステップＳ３３〜Ｓ４７の処理を繰り返すことにより、今日再与信確認が必要な各予約について再与信確認を行う。そして、システム制御部１４は、全ての予約情報を選択したと判定した場合には（ステップＳ４６：ＮＯ）、再与信確認処理を終了させる。
【０１１１】
図１０は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の決済方法変更処理における処理例を示すフローチャートである。
【０１１２】
図１０に示すように、システム制御部１４は、予約情報ＤＢ１２ｃから、再与信確認フラグがＯＮに設定されている予約情報のうち、与信確認結果にＮＧが設定され、且つ、チェックイン日の１０日前が今日である予約情報を検索する（ステップＳ７１）。次いで、システム制御部１４は、検索した予約情報のうち１つを選択する（ステップＳ７２）。次いで、システム制御部１４は、選択した予約情報に含まれる決済方法情報を「現地決済」に変更する（ステップＳ７３）。次いで、システム制御部１４は、現地決済通知メールを送信する（ステップＳ７４）。この処理の内容は、図９に示す再与信確認処理のステップＳ５５の処理内容と同様である。
【０１１３】
次いで、システム制御部１４は、ステップＳ７１で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する（ステップＳ７５）。このとき、システム制御部１４は、まだ選択していない予約情報があると判定した場合には（ステップＳ７５：ＹＥＳ）、まだ選択していない予約情報のうち１つを選択する（ステップＳ７６）。次いで、システム制御部１４は、ステップＳ７３に移行する。システム制御部１４は、ステップＳ７３〜Ｓ７６の処理を繰り返すことにより、再与信確認で与信を確認することができなかった予約のうち、チェックイン日の１０日前が今日である各予約について、決済方法を現地決済に変更する。そして、システム制御部１４は、全ての予約情報を選択したと判定した場合には（ステップＳ７５：ＮＯ）、決済方法変更処理を終了させる。
【０１１４】
図１１は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４のオプション料金登録処理における処理例を示すフローチャートである。
【０１１５】
オプション料金が発生した場合、宿泊施設の提供者は、オプション料金を登録するために、宿泊施設端末３を操作する。このとき、提供者は、オプション料金、予約番号等を入力する。すると、宿泊施設端末３は、オプション料金登録リクエストを宿泊施設予約サーバ１へ送信する。オプション料金登録処理は、宿泊施設予約サーバ１がオプション料金登録リクエストを受信したときに開始される。
【０１１６】
図１１に示すように、システム制御部１４は、予約情報ＤＢ１２ｃから、オプション料金登録リクエストに含まれる予約番号に対応する予約情報を検索する。次いで、システム制御部１４は、検索した予約情報に含まれる決済方法情報に「オンラインカード決済」が設定され、且つ、検索した予約情報に含まれる与信確認結果にＯＫが設定されているか否かを判定する（ステップＳ８１）。
【０１１７】
このとき、システム制御部１４は、決済方法情報に「オンラインカード決済」が設定されていないと判定した場合、または、与信確認結果にＯＫが設定されていないと判定した場合には（ステップＳ８１：ＮＯ）、与信確認エラー終了ページを、オプション料金登録リクエストの送信元の宿泊施設端末３へ送信する（ステップＳ８２）。与信確認エラー終了ページは、オプション料金について与信を確認することができなかった旨のメッセージを表示するＷｅｂページである。システム制御部１４は、ステップＳ８２の処理を終えると、オプション料金登録処理を終了させる。
【０１１８】
一方、システム制御部１４は、決済方法情報に「オンラインカード決済」が設定されており、且つ、与信確認結果にＯＫが設定されていると判定した場合には（ステップＳ８１：ＹＥＳ）、検索した予約情報に含まれるクレジットカード情報に基づいて、オプション料金を決済するための与信を確認する（ステップＳ８３）。この処理の内容は、図８に示す再与信確認処理のステップＳ３４の処理内容と基本的に同様である。ただし、システム制御部１４は、宿泊料金の代わりに、オプション料金を与信確認リクエストに設定する。
【０１１９】
次いで、システム制御部１４は、与信を確認することができたか否かを判定する（ステップＳ８４）。このとき、システム制御部１４は、与信を確認することができなかったと判定した場合には（ステップＳ８４：ＮＯ）、ステップＳ８２に移行する。一方、システム制御部１４は、与信を確認することができたと判定した場合には（ステップＳ８４：ＹＥＳ）、ステップＳ８３において決済サーバ２から受信した与信確認応答に含まれる承認番号をオプション料金承認番号として、検索した予約情報中に設定する。次いで、システム制御部１４は、検索した予約情報に含まれるオプション料金決済フラグをＯＮに設定する。また、システム制御部１４は、オプション料金登録リクエストに含まれるオプション料金を、検索した予約情報中に設定する（ステップＳ８５）。次いで、システム制御部１４は、与信確認正常終了ページを、オプション料金登録リクエストの送信元の宿泊施設端末３へ送信する（ステップＳ８６）。与信確認正常終了ページは、オプション料金について与信を確認することができた旨のメッセージを表示するＷｅｂページである。システム制御部１４は、ステップＳ８６の処理を終えると、オプション料金登録処理を終了させる。
【０１２０】
図１２は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の決済処理における処理例を示すフローチャートである。
【０１２１】
図１２に示すように、システム制御部１４は、予約情報ＤＢ１２ｃから、決済方法情報に「オンラインカード決済」が設定されている予約情報のうち、チェックアウト日の翌日が今日である予約情報を検索する（ステップＳ９１）。次いで、システム制御部１４は、検索した予約情報のうち１つを選択する（ステップＳ９２）。次いで、システム制御部１４は、選択した予約情報に含まれるオプション料金決済フラグがＯＮに設定されているか否かを判定する（ステップＳ９３）。このとき、システム制御部１４は、オプション料金決済フラグがＯＮに設定されていないと判定した場合には（ステップＳ９３：ＮＯ）、選択した予約情報に含まれるクレジットカード情報に基づいて、選択した予約情報に含まれる宿泊料金を決済する（ステップＳ９４）。具体的に、システム制御部１４は、決済リクエストを決済サーバ２へ送信する。決済リクエストは、選択された予約情報に含まれるクレジットカード情報、利用額、承認番号等を含む。システム制御部１４は、利用額及び承認番号として、選択された予約情報に含まれる宿泊料金及び宿泊料金承認番号を設定する。決済サーバ２は、決済リクエストを受信すると、決済リクエストに含まれる承認番号に対応してユーザの口座から引き落とす利用料金を、決済リクエストに含まれる宿泊料金で確定する処理を行う。システム制御部１４は、ステップＳ９４の処理を終えると、ステップＳ９６に移行する。
【０１２２】
一方、システム制御部１４は、オプション料金決済フラグがＯＮに設定されていると判定した場合には（ステップＳ９３：ＹＥＳ）、決済手段として、選択した予約情報に含まれるクレジットカード情報に基づいて、選択した予約情報に含まれる宿泊料金及びオプション料金を含む利用料金を決済する（ステップＳ９５）。具体的に、システム制御部１４は、ステップＳ９４と同様の方法で、宿泊料金を決済する。また、システム制御部１４は、選択された予約情報に含まれるオプション料金及びオプション料金承認番号を設定した決済リクエストを決済サーバ２へ送信する。これにより、システム制御部１４は、オプション料金を決済する。システム制御部１４は、ステップＳ９５の処理を終えると、ステップＳ９６に移行する。
【０１２３】
ステップＳ９６において、システム制御部１４は、ステップＳ９１で検索した予約情報の中にまだ選択していない予約情報があるか否かを判定する。このとき、システム制御部１４は、まだ選択していない予約情報があると判定した場合には（ステップＳ９６：ＹＥＳ）、まだ選択していない予約情報のうち１つを選択する（ステップＳ９７）。次いで、システム制御部１４は、ステップＳ９３に移行する。システム制御部１４は、ステップＳ９３〜Ｓ９７の処理を繰り返すことにより、今日決済が必要な各予約について利用料金の決済を行う。そして、システム制御部１４は、全ての予約情報を選択したと判定した場合には（ステップＳ９６：ＮＯ）、決済処理を終了させる。
【０１２４】
以上説明したように、本実施形態によれば、宿泊施設予約サーバ１のシステム制御部１４が、オンラインカード決済が指定される予約として、利用日までの日数が与信日数を超える予約が要求された場合、指定されたクレジットカードの有効性を確認し、有効であると確認することができた場合、予約を受け付け、指定されたクレジットカードのクレジットカード情報を含む予約情報を記憶部１２に記憶させ、予約が受け付けられた宿泊施設の利用日までの日数が与信日数以下になる日以降に、記憶部１２に記憶されたクレジットカード情報に基づいて、指定されたクレジットカードの有効性を確認し、有効であると確認することができなかった場合、決済方法を、指定されたクレジットカードでの決済とは異なる方法に変更することを示す決済方法変更予告メールまたは現地決済通知メールを出力する。従って、宿泊施設予約サーバ１は、予約日から利用日までの日数が与信日数を超える場合であっても、指定されたクレジットカードが有効であることを確認して予約を受け付けることができる。また、指定されたクレジットカードが予約の後に有効ではなくなった場合には、決済方法が変更されるので、宿泊施設予約サーバ１は、利用料金の決済の安全性を保ちつつ予約を維持することができる。
【０１２５】
また、システム制御部１４は、決済日までの日数が与信日数を超える予約が要求された場合にも、指定されたクレジットカードの有効性を確認し、有効であると確認することができた場合、予約を受け付け、指定されたクレジットカードのクレジットカード情報を含む予約情報を記憶部１２に記憶させ、予約が受け付けられた宿泊施設の宿泊料金の決済日までの日数が与信日数以下になる日以降に、記憶部１２に記憶されたクレジットカード情報に基づいて、指定されたクレジットカードの有効性を確認する。従って、利用料金の決済の安全性を高めることができる。
【０１２６】
また、システム制御部１４が、第１回再与信確認により、指定されたクレジットカードが有効であると確認することができなかった後、記憶部１２に記憶されたクレジットカード情報に基づいて、指定されたクレジットカードの有効性を確認し、有効であると確認することができた場合、決済方法を、指定されたクレジットカードで決済する方法にすることを示すオンラインカード決済通知メールを送信する。従って、予約の後に、ユーザが利用したいクレジットカードで利用料金を支払うための信用が一度なくなった場合であっても、その後信用が戻った場合に、決済方法を、ユーザが利用したいクレジットカードによる決済にすることができる。
【０１２７】
また、システム制御部１４が、予約が受け付けられた宿泊施設の利用日数が与信日数以上である場合、ＮＧ時再与信確認によってオンラインカード決済が有効であると確認することができた後、予約が受け付けられた宿泊施設のチェックイン日の前日までに、指定されたクレジットカードの有効性を確認する。チェックイン直前再与信確認によって、与信期間に含まれる宿泊施設の利用日を多くすることができるので、ユーザが予約をキャンセルする場合や、ユーザが何の連絡もなくチェックイン日になっても宿泊施設に現れない場合であっても、宿泊施設の提供者がキャンセル料を決済するかどうかの決定をするための猶予期間をより長く設けることができる。
【０１２８】
また、システム制御部１４が、予約が受け付けられた宿泊施設の利用日数が与信日数以上である場合、チェックイン直前再与信確認によって有効であると確認することができた後、決済日までの日数が与信日数以下になる日以降に、記憶部１２に記憶されたクレジットカード情報に基づいて、指定されたクレジットカードの有効性を確認し、有効であると確認することができなかった場合、現地決済通知メールを出力する。従って、利用料金の決済の安全性を高めることができる。
【０１２９】
また、システム制御部１４が、ＮＧ時再与信確認によってオンラインカード決済が有効であると確認することができた宿泊料金以外に、予約された宿泊施設の利用によってオプション料金が発生した場合、記憶部１２に記憶されたクレジットカード情報に基づいて、宿泊料金と発生したオプション料金とを含む利用料金を、指定されたクレジットカードで決済する。従って、ユーザが宿泊施設を利用した際に新たに料金が発生した場合に、ユーザは、決済の手続を行わなくても、ユーザが利用したいクレジットカードで決済することができる。
【０１３０】
また、システム制御部１４が、第１回再与信確認によってクレジットカードが有効であると確認することができなかった場合、エラー種別が「限度額オーバー」であるか否かを判定し、エラー種別が「限度額オーバー」であると判定した場合に、ＮＧ時再与信確認を行う。従って、宿泊施設予約サーバ１が不必要にＮＧ時再与信確認を行うことを抑制することができる。
【０１３１】
また、システム制御部１４が、第１回再与信確認の日を含む再与信確認履歴と、ＮＧ時再与信確認の日を含む再与信確認履歴とを記憶部１２に記憶させ、記憶部１２に記憶された再与信確認履歴に基づいて、指定されたクレジットカードが有効になる日を推定し、推定した日に、ＮＧ時再与信確認を行う。従って、宿泊料金を支払うための信用が戻ることによってクレジットカードが有効であると確認することができる蓋然性を高めることができる。
【０１３２】
なお、上記実施形態においては、宿泊施設の提供に対して本発明を適用していた。しかしながら、予約時に利用日が決定されるサービスであれば、如何なるサービスに対しても本発明を適用することができる。このようなサービスとしては、例えば、ゴルフ場等の競技施設の提供や、航空機、列車、船舶、乗用車等の交通機関による人の輸送等がある。
【符号の説明】
【０１３３】
１  宿泊施設予約サーバ
２  決済サーバ
３  宿泊施設端末
４  ユーザ端末
１１  通信部
１２  記憶部
１２ａ  会員情報ＤＢ
１２ｂ  宿泊施設情報ＤＢ
１２ｃ  予約情報ＤＢ
１３  入出力インターフェース
１４  システム制御部
１４ａ  ＣＰＵ
１４ｂ  ＲＯＭ
１４ｃ  ＲＡＭ
１５  システムバス
ＮＷ  ネットワーク
Ｓ  情報処理システム
【図１】
2013182314.tif 000003
【図２】
2013182314.tif 000004
【図３】
2013182314.tif 000005
【図４】
2013182314.tif 000006
【図５】
2013182314.tif 000007
【図６】
2013182314.tif 000008
【図７】
2013182314.tif 000009
【図８】
2013182314.tif 000010
【図９】
2013182314.tif 000011
【図１０】
2013182314.tif 000012
【図１１】
2013182314.tif 000013
【図１２】
2013182314.tif 000014