CN103415862A - 信息处理装置、信息处理方法、信息处理程序和记录介质 - Google Patents

Abstract

即使在预约时没有用于利用用户希望利用的信用卡来结算利用费用的信用的情况下，也接受在信用已恢复时能够利用该信用卡来结算的预约。信息处理装置在针对预约请求不能够确认指定的信用卡的有效性的情况下，接受预约，并将指定的信用卡的信息存储到存储单元中。在接受了预约后，信息处理装置根据存储单元中存储的信息，确认指定的信用卡的有效性。此时，信息处理装置在能够确认为有效的情况下，输出表示将结算方法设为利用指定的信用卡进行的结算的信息。另一方面，信息处理装置在不能够确认为有效的情况下，输出表示将结算方法设为与利用指定的信用卡进行的结算不同的方法的信息。

Description

信息处理装置、信息处理方法、信息处理程序和记录介质

技术领域

本发明涉及进行用于利用信用卡来结算预约服务的利用费用的处理的信息处理装置和信息处理方法的技术领域。 

背景技术

以往，已知有如下预约系统：在互联网上，接受例如利用住宿设施的住宿预约等服务的预约。在这样的预约系统中，存在能够进行在线卡结算的系统。当用户在预约时指定在线卡结算作为结算方法时，预约系统在被预约的服务的利用日以后的日子，自动进行基于信用卡的利用费用的结算处理。在该情况下，用户不需要在利用服务时执行结算手续。 

在指定了在线卡结算作为结算方法的情况下，预约系统在预约时进行信用卡的有效性确认。在有效性确认中，预约系统在判断为不能够利用指定的信用卡来结算利用费用的情况下，不接受基于用户指定的信用卡的结算进行的预约。例如，在专利文献1中记载了如下技术：在不能够确认授信的情况下，要求顾客变更信用卡或取消购买。 

现有技术文献 

专利文献1：日本特开2002-163527号公报 

发明内容

发明要解决的问题 

但是，即使用户指定的信用卡的信息自身是有效的，有时也不能够利用指定的信用卡来结算。例如，可举出如下情况：在预约时，作为预约对象的服务的利用费用超过信用卡的可用额度。在这样的情况下，如果不接受预约，则用户会放弃预约。这样，服务的提供者会失去提供服务的机会。此外，用户不能够利用希望利用的信用卡来预约服务。 

本发明是鉴于以上方面而完成的，目的在于提供如下所述的信息处理装置、信息 处理方法、信息处理程序和记录介质：即使在预约时没有用于利用用户希望利用的信用卡来支付利用费用的信用的情况下，也接受在信用已恢复时能够利用该信用卡来结算的预约。 

用于解决问题的手段 

为了解决上述问题，权利要求1所述的发明的特征在于，具有：预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。 

根据本发明，即使在预约时没有用于利用用户希望利用的信用卡支付利用费用的信用的情况下，之后，也能够在信用已恢复的情况下，将结算方法设定为基于用户希望利用的信用卡的结算。因此，信息处理装置能够接受用户希望利用的信用卡能够结算的预约。 

权利要求2所述的发明的特征在于，在权利要求1所述的信息处理装置中，在由所述预约单元接了预约的服务的利用天数为与授予利用所述信用卡进行支付的信用的期间相应的授信天数以上的情况下，所述确认单元在接受了预约的服务的利用开始日的前一日之前，确认所述指定的信用卡的有效性。 

权利要求3所述的发明的特征在于，在权利要求2所述的信息处理装置中，还具有第2确认单元，该第2确认单元在能够通过所述确认单元确认为有效后，在距离所述利用费用的结算日的天数为所述授信天数以下的日子以后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性，所述输出单元在不能够通过所述第2确认单元确认为有效的情况下，输出表示将结算方法变更为与利用所述指定的信用卡进行的结算不同的方法的信息。 

根据本发明，为了在授信期间内进行结算，在服务的利用开始日之前确认信用卡为有效后，再次确认信用卡的有效性，此时，在不能够确认为有效的情况下，能够变更结算方法。因此，能够提高服务利用费用结算的安全性。 

根据本发明，为了在授信期间内进行结算，对于在确认信用卡的有效性时确认日为利用开始日以后的利用天数的预约，能够在利用开始日之前确认信用卡的有效性。因此，服务提供者能够在确保用户能够利用信用卡来支付利用费用的状态下，开始提供服务。 

权利要求4所述的发明的特征在于，在权利要求1～3中的任意一项所述的信息处理装置中，还具有结算单元，在除了能够通过所述确认单元确认有效性的所述利用费用以外、还因利用预约的服务而产生费用的情况下，该结算单元根据所述存储单元中存储的所述信息，利用所述指定的信用卡来结算包含所述产生的费用在内的所述利用费用。 

根据本发明，在用户利用服务时新产生费用的情况下，用户即使不进行结算手续，也能够利用用户希望利用的信用卡来结算。 

权利要求5所述的发明的特征在于，在权利要求1～4中的任意一项所述的信息处理装置中，还具有判定单元，该判定单元判定针对所述请求不能够确认所述指定的信用卡为有效的原因是否是所述利用费用超过所述指定的信用卡的可用额度，所述预约单元在通过所述判定单元判定为所述原因是所述利用费用超过所述可用额度的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中。 

根据本发明，在请求预约时不能够确认信用卡有效的原因是作为预约对象的服务的利用费用超过信用卡的可用额度这样的原因的情况下，接受预约，然后再次确认信用卡的有效性。信用卡的可用额度有可能从预约时起增大。因此，信息处理装置能够仅接受可确认有效性的概率较高的预约。由此，信息处理装置能够抑制不必要地再次确认信用卡的有效性。 

权利要求6所述的发明的特征在于，在权利要求1～5中的任意一项所述的信息处理装置中，还具有存储控制单元和推测单元，所述存储控制单元将与所述请求对应的所述指定的信用卡的有效性的确认日和所述确认单元确认的有效性的确认日存储在确认日存储单元中，所述推测单元根据所述确认日存储单元中存储的所述确认日，推测所述指定的信用卡成为有效的日子，所述确认单元在由所述推测单元推测出的日子确认所述指定的信用卡的有效性。 

根据本发明，在推测指定的信用卡成为有效的日子进行有效性的确认，因而能够提高信用卡因用于支付利用费用的信用恢复而能够确认为有效的概率。 

权利要求7所述的发明是由计算机执行的信息处理方法，其特征在于，该信息处理方法包含：预约步骤，针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；确认步骤，在所述预约单元中接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；输出步骤，在所述确认步骤中能够确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在所述确认步骤中不能够确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。 

权利要求8所述的发明的特征在于，使计算机作为以下单元来发挥作用：预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息，。 

权利要求9所述的发明的特征在于，以计算机能够读取的方式记录有使计算机作为以下单元来发挥作用的信息处理程序：预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。 

发明效果 

根据本发明，即使在预约时没有利用用户希望利用的信用卡来结算利用费用的、 用于支付的信用的情况下，之后，也能够在信用已恢复的情况下，将结算方法设定为基于用户希望利用的信用卡的结算。因此，信息处理装置能够接受用户希望利用的信用卡能够结算的预约。 

附图说明

图1是示出一个实施方式的信息处理系统S的概要结构的一例的图 

图2是示出从预约到结算的处理的流程的图。 

图3是示出结算方法变更页面的画面显示例的图。 

图4是示出住宿设施的利用天数为授信期间的天数以上的情况下从预约到结算的处理的流程的图。 

图5是示出一个实施方式的住宿设施预约服务器1的概要结构的一例的框图。 

图6的（a）是示出被登记到会员信息数据库12a中的内容的一例的图，（b）是示出被登记到住宿设施信息数据库12b中的内容的一例的图，（c）是示出被登记到预约信息数据库12c中的内容的一例的图。 

图7是示出一个实施方式的住宿设施预约服务器1的系统控制部14的预约处理中的处理例的流程图。 

图8是示出一个实施方式的住宿设施预约服务器1的系统控制部14的结算方法变更预约处理中的处理例的流程图。 

图9是示出一个实施方式的住宿设施预约服务器1的系统控制部14的再授信确认处理中的处理例的流程图。 

图10是示出一个实施方式的住宿设施预约服务器1的系统控制部14的再再授信确认处理中的处理例的流程图。 

图11是示出一个实施方式的住宿设施预约服务器1的系统控制部14的可选费用登记处理中的处理例的流程图。 

图12是示出一个实施方式的住宿设施预约服务器1的系统控制部14的结算处理中的处理例的流程图。 

具体实施方式

下面，参照附图对本发明的实施方式进行详细说明。此外，下面说明的实施方式 是将本发明应用于信息处理系统的情况下的实施方式。 

[1.信息处理系统的结构和功能概要] 

首先，使用图1，对本实施方式的信息处理系统S的结构和功能概要进行说明。图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用“成功”表示能够确认授信的情况，用“失败”表示不能够确认授信的情况。 

如图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将结算方法设为在线卡结算而接受预约。然后，在图2的（3）中，住宿设施预约服务器1确认第1希望的信用卡的授信。此时，住宿设施预约服务器1在能够确认授信的情况下，不变更结算方法。并且，住宿设施预约服务器1输出表示设为基于第1希望的信用卡 的在线卡结算的信息。作为该信息，住宿设施预约服务器1例如向进行了预约的用户地址发送在线卡结算通知邮件。在线卡结算通知邮件是通知“结算方法没有改变而仍为基于第1希望的信用卡的在线卡结算”的电子邮件。然后，住宿设施预约服务器1利用第1希望的信用卡结算住宿费用（图2的（4））。 

在再授信确认中不能够确认授信的情况下，住宿设施预约服务器1将结算方法从在线卡结算变更为现场结算。并且，住宿设施预约服务器1输出表示将结算方法设为与在线卡结算不同的方法的信息。针对该信息，住宿设施预约服务器1例如向进行了预约的用户地址发送现场结算通知邮件。现场结算通知邮件是通知“结算方法从在线卡结算被变更为现场结算”的电子邮件。此外，通过用户终端4接收到现场结算通知邮件的用户例如能够指定与预约时指定的信用卡不同的信用卡，将结算方法变更为在线卡结算。 

在用户选择了不变更结算方法而仍为在线卡结算、但是可以在在线卡结算中利用第2希望的信用卡的情况下，在图2的（1）中，住宿设施预约服务器1确认第2希望的信用卡的授信。此时，住宿设施预约服务器1在不能够确认授信的情况下不接受预约，再次发送结算方法变更页面。另一方面，住宿设施预约服务器1在能够确认授信的情况下，将结算方法设为在线卡结算而接受预约。然后，在图2的（3）中，住宿设施预约服务器1确认第1希望的信用卡的授信，在能够确认授信的情况下，发送在线卡结算通知邮件。然后，住宿设施预约服务器1利用第1希望的信用卡来结算住宿费用（图2的（4））。 

在不能够确认第1希望的信用卡的授信的情况下，住宿设施预约服务器1确认第2希望的信用卡的授信。此时，住宿设施预约服务器1在能够确认授信的情况下，不变更结算方法。然后，住宿设施预约服务器1利用第2希望的信用卡来结算住宿费用（图2的（4））。另一方面，住宿设施预约服务器1在不能够确认授信的情况下，将结算方法变更为现场结算，发送现场结算通知邮件。 

在用户选择了将结算方法变更为现场结算的情况下，在图2的（1）中，住宿设施预约服务器1将结算方法设为现场结算而接受预约。然后，在图2的（3）中，住宿设施预约服务器1确认第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.住宿设施预约服务器的结构］ 

接下来，使用图5和图6，对住宿设施预约服务器1的结构进行说明。 

图5是示出本实施方式的住宿设施预约服务器1的概要结构的一例的框图。如图5所示，住宿设施预约服务器1具有通信部11、存储部12、输入/输出接口13和系统控制部14。并且，系统控制部14和输入/输出接口13经由系统总线15相连接。 

通信部11与网络NW连接，对与用户终端4等的通信状态进行控制。 

存储部12例如由硬盘驱动器等构成。在该存储部12中，构筑有会员信息数据库12a、住宿设施信息数据库12b、预约信息数据库12c等数据库。“数据库”是数据库的缩略语。此外，存储部12是本发明中的存储单元的一例。 

图6的（a）是示出被登记到会员信息数据库12a中的内容的一例的图。在会员信息数据库12a中，登记有与在信息处理系统S中进行了会员登记的用户相关的会员信息。具体而言，在会员信息数据库12a中，与每个用户相对应地登记有用户ID、密码、昵称、姓名、出生年月日、性別、邮政编码、住址、电话号码、电子邮件地址和登记信用卡信息等。用户ID是用户的识别信息。登记信用卡信息是由用户登记的信用卡的卡信息。在登记信用卡信息中例如设定有信用卡公司、卡编号、有效期限、名义人的名称等信息。用户通过预先登记卡信息，可以无需在每次预约时输入卡信息。 

图6的（b）是示出被登记到住宿设施信息数据库12b中的内容的一例的图。在住宿设施信息数据库12b中，登记有与住宿设施相关的住宿设施信息。具体而言，在住宿设施信息数据库12b中，与每个住宿设施相对应地登记有设施ID、住宿设施名、邮政编码、住址、电话号码、FAX号码、电子邮件地址、规划信息等住宿设施的属性。设施ID是住宿设施的识别信息。规划信息是与住宿设施提供的住宿规划相关的信息。住宿规划是例如由住宿设施的提供者规划的住宿服务。在规划信息中，针对每一住宿规划设定有例如规划ID、住宿规划名、客房类型ID、住宿规划的内容、1晚的住宿费用的说明等住宿规划的属性。规划ID是住宿规划的识别信息。客房类型ID是表示客房的类型的识别信息。 

图6的（c）是示出登记到预约信息数据库12c中的内容的一例的图。在预约信 息数据库12c中，登记有与被接受的预约相关的预约信息。具体而言，在预约信息数据库12c中，与每一预约相对应地登记有预约编号、预约日、用户ID、设施ID、规划ID、客房类型、入住日、退房日、利用人数、住宿费用、结算方法信息和在线卡结算管理信息等信息。预约编号是预约的识别信息。用户ID表示进行了预约的用户。设施ID表示被预约的住宿设施。规划ID和客房类型ID表示被预约的住宿规划和客房类型。住宿费用是预约时确定的利用费用。住宿费用根据住宿规划、客房类型、住宿天数和利用人数来确定。结算方法信息是表示结算方法的信息。在结算方法信息中，设定有“现场结算”或“在线卡结算”中的任意一个。 

在线卡结算管理信息是与在线卡结算相关的信息。在线卡结算管理信息中设定有第1信用卡信息、第2信用卡信息、利用卡类別、授信确认结果、住宿费用认可编号、可选费用结算标志、可选费用、可选费用认可编号、再授信确认标志、再授信确认日、再再授信确认标志和再再授信确认日。第1信用卡信息是由用户指定的第1希望的信用卡的卡信息。第2信用卡信息是由用户指定的第2希望的信用卡的卡信息。利用卡类別是表示用于在线卡结算的信用卡的种类的信息。利用卡类別设定为“第1卡”或“第2卡”中的任意一个。“第1卡”表示利用第1希望的信用卡。“第2卡”表示利用第2希望的信用卡。授信确认结果表示最新的授信确认中的确认结果。在授信确认结果被设定为成功的情况下，表示能够确认授信。在授信确认结果被设定为失败的情况下，表示不能够确认授信。住宿费用认可编号是针对住宿费用的结算认可信用卡的授信的情况下，从结算服务器2发送给住宿设施预约服务器1的认可编号。认可编号是授信被认可的交易的识别信息。可选费用结算标志是表示是否利用在线卡结算来结算可选费用的信息。在可选费用结算标志被设定为开的情况下，表示利用在线卡结算来结算可选费用。在可选费用结算标志被设定为关的情况下，表示不利用在线卡结算来结算可选费用。可选费用认可编号是针对可选费用的结算认可信用卡的授信的情况下，从结算服务器2发送给住宿设施预约服务器1的认可编号。再授信确认标志是表示是否需要再授信确认的信息。在再授信确认标志被设定为开的情况下，表示需要再授信确认。在再授信确认标志被设定为关的情况下，表示不需要再授信确认。再授信确认日表示进行再授信确认的日子。再再授信确认标志是表示是否需要再再授信确认的信息。在再再授信确认标志被设定为开的情况下，表示需要再再授信确认。在再再授信确认标志被设定为关的情况下，表示不需要再再授信确认。再再授信确认日表示 进行再再授信确认的日子。 

接下来，对存储部12中存储的其它的信息进行说明。在存储部12中，存储有用于显示Web页面的HTML（Hyper Text 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.信息处理系统的动作］ 

接下来，使用图7～图12，对信息处理系统S的动作进行说明。 

图7是示出本实施方式的住宿设施预约服务器1的系统控制部14的预约处理中的处理例的流程图。 

例如，用户在住宿设施站点检索住宿设施，选择期望的住宿设施、住宿规划和客房类型。接下来，用户选择入住日、退房日和利用人数。这时，在用户终端4的画面上显示结算方法指定页面。结算方法指定页面是用于指定结算方法的Web页面。在此，用户在选择在线卡结算作为结算方法时，输入用于结算的信用卡的卡信息。此时， 用户能够指定在会员信息中登记了信息的信用卡。在该情况下，用户不输入卡信息。用户在进行了必要的选择和输入后，选择用于请求预约的按钮。这样，用户终端4向住宿设施预约服务器1发送预约请求。预约请求包含用户ID，用户所选择的住宿设施、与住宿规划和客房类型对应的设施ID、规划ID和客房ID、入住日、退房日以及利用人数。此外，预约请求包含：表示是否利用在会员信息中登记了信息的信用卡的信息；以及由用户输入的卡信息。在住宿设施预约服务器1接收到预约请求时开始预约处理。 

如图7所示，系统控制部14判定用户所选择的结算方法是否是在线卡结算（步骤S1）。此时，系统控制部14在判定为结算方法不是在线卡结算的情况下（步骤S1：否），在结算方法信息中设定“现场结算”。此外，系统控制部14将再授信确认标志和再再授信确认标志设定为关（步骤S2）。接下来，系统控制部14登记预约信息（步骤S3）。具体而言，系统控制部14生成新的预约编号。接下来，系统控制部14生成包含预约编号、预约请求中包含的信息、进行了设定的结算方法信息、再授信确认标志和再再授信确认标志等在内的预约信息。接下来，系统控制部14将生成的预约信息登记到预约信息数据库12c中。系统控制部14在结束步骤S3的处理后，结束预约处理。 

另一方面，系统控制部14在判定为结算方法为在线卡结算的情况下（步骤S1：是），根据由用户指定的信用卡的卡信息，确认授信（步骤S4）。具体而言，系统控制部14根据预约请求中包含的设施ID、规划ID、客房类型ID和利用人数，计算住宿费用。此外，系统控制部14取得用户指定的信用卡的卡信息。在用户输入了卡信息的情况下，根据预约信息请求取得卡信息。另一方面，系统控制部14在用户指定了已登记的信用卡的情况下，从会员信息数据库12a中检索与请求预约的用户的用户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：是）。在该情况下，系统控制部14进行在线卡结算管理信息的设定（步骤S6）。具体而言，系统控制部14在结算方法信息中设定“在线卡结算”。此外，系统控制部14在第1信用卡信息中设定在步骤S4中取得的卡信息。此外，系统控制部14在利用卡类別中设定“第1卡”。此外，系统控制部14在授信确认结果中设定“成功”。此外，系统控制部14在住宿费用认可编号中设定授信确认响应中包含的认可编号。此外，系统控制部14将可选费用结算标志设定为关。此外，系统控制部14将再授信确认标志和再再授信确认标志设定为关。 

接下来，系统控制部14登记包含由用户指定的信用卡的卡信息在内的预约信息（步骤S7）。具体而言，系统控制部14生成包含新预约编号、预约请求中包含的信息，进行了设定的在线卡结算管理信息在内的预约信息。接下来，系统控制部14将生成的预约信息登记到预约信息数据库12c中。系统控制部14在结束步骤S7的处理后，结束预约处理。 

另一方面，系统控制部14在接收到不包含认可编号的授信确认响应的情况下， 判定为不能够确认授信（步骤S5：否）。在该情况下，系统控制部14取得从结算服务器2接收到的授信确认响应中包含的错误类别。并且，系统控制部14作为判定单元，判定错误类别是否是“超过限额”（步骤S8）。此时，系统控制部14在判定为错误类别不是“超过限额”的情况下（步骤S8：否），向作为预约请求的发送源的用户终端4发送结算方法指定页面（步骤S9）。系统控制部14在结束步骤S9的处理后，结束预约处理。在结算方法指定页面中，用户再次指定结算方法。并且，在用户选择了用于请求预约的按钮时，用户终端4向住宿设施预约服务器1发送预约请求。 

另一方面，系统控制部14在判定为错误类别是“超过限额”的情况下（步骤S8：是），判定从明日起到预约请求中包含的入住日的前一日为止是否存在授信额度清除日（步骤S10）。此外，授信额度清除日有时会根据每一信用卡公司而不同。在该情况下，系统控制部14根据在步骤S4中取得的卡信息中包含的信用卡公司的信息，确定授信额度清除日。系统控制部14在判定为授信额度清除日不存在的情况下（步骤S10：否），转入步骤S9。即，系统控制部14在授信额度清除日不存在的情况下，不接受基于利用第1希望的信用卡的在线卡结算的预约。 

另一方面，系统控制部14在判定为存在授信额度清除日的情况下（步骤S10：是），向作为预约请求的发送源的用户终端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：否），将结算方法信息变更为“现场结算”（步骤S22）。接下来，系统控制部14转入步骤S29。 

另一方面，系统控制部14在判定为结算方法是在线卡结算的情况下（步骤S21：是），判定是否指定了第2希望的信用卡（步骤S23）。此时，系统控制部14在判定为未指定第2希望的信用卡的情况下（步骤S23：否），转入步骤S28。另一方面，系统控制部14在判定为指定了第2希望的信用卡的情况下（步骤S23：是），根据第2希望的信用卡的卡信息，确认授信（步骤S24）。该处理的内容与图7所示的预约处理的步骤S4的处理内容基本相同。其中，系统控制部14根据结算方法变更请求取得第2希望的信用卡的卡信息。并且，系统控制部14在授信确认请求中设定取得的卡信息。 

接下来，系统控制部14判定是否能够确认第2希望的信用卡的授信（步骤S25）。此时，系统控制部14在判定为不能够确认授信的情况下（步骤S25：否），向作为预约请求的发送源的用户终端4发送结算方法指定页面（步骤S26）。系统控制部14在结束步骤S26的处理后，结束结算方法变更预约处理。另一方面，系统控制部14在判定为能够确认授信的情况下（步骤S25：是），在第2信用卡信息中设定在步骤S24中取得的卡信息。此外，系统控制部14在住宿费用认可编号中设定在步骤S24中接收到的授信确认响应中包含的认可编号（步骤S27）。接下来，系统控制部14转入步骤S28。 

在步骤S28中，系统控制部14在结算方法信息中设定“在线卡结算”。接下来，系统控制部14进行在线卡结算管理信息的主要设定（步骤S29）。具体而言，系统控制部14在第1信用卡信息中，设定在存储部12中与请求预约的用户ID相对应地存储的卡信息。此外，系统控制部14在利用卡类别中设定“第1卡”。此外，系统控制部14在授信确认结果中设定“失败”。此外，系统控制部14将可选费用结算标志设定为关。此外，系统控制部14将再授信确认标志设定为开。此外，系统控制部14将存在于从明日起到入住日的前一日为止的期间的授信额度清除日设定为再授信确认日。此时，在存在多个授信额度清除日的情况下，系统控制部14例如可以将最接近入住日的授信额度清除日设定为再授信确认日。其原因在于，使得在再授信确认中， 能够基于被确保的授信额度来进行结算。 

接下来，系统控制部14根据在存储部12中与请求预约的用户ID相对应地存储的入住日和退房日，计算住宿设施的利用天数。并且，系统控制部14判定利用天数是否不足授信天数（步骤S30）。此时，系统控制部14在判定为利用天数不足授信天数的情况下（步骤S30：是），将再再授信确认标志设定为关（步骤S31）。接下来，系统控制部14转入步骤S33。 

另一方面，系统控制部14在判定为利用天数为授信天数以上的情况下（步骤S30：否），将再再授信确认标志设定为开。此外，系统控制部14将退房日的次日设定为结算日。并且，系统控制部14将距离结算日授信天数前的日子设定为再再授信确认日（步骤S32）。接下来，系统控制部14转入步骤S33。 

在步骤S33中，系统控制部14作为预约单元，登记包含由用户指定的信用卡的卡信息的预约信息。具体而言，系统控制部14生成包含新预约编号、在存储部12中与请求预约的用户ID相对应地存储的信息、进行了设定的结算方法信息、第1信用卡信息、第2信用卡信息、利用卡类别、授信确认结果、住宿费用认可编号、可选费用结算标志、再授信确认标志、再授信确认日、再再授信确认标志和再再授信确认日等在内的预约信息。接下来，系统控制部14将生成的预约信息登记到预约信息数据库12c中。系统控制部14通过登记预约信息，接受所请求的预约。系统控制部14在结束步骤S33的处理后，结束预约处理。 

图9是示出本实施方式的住宿设施预约服务器1的系统控制部14的再授信确认处理中的处理例的流程图。住宿设施预约服务器1每日执行一次再授信确认处理、后述的再再授信确认处理和结算处理。住宿设施预约服务器1也可以持续执行再授信确认处理、再再授信确认处理和结算处理。 

如图9所示，系统控制部14从预约信息数据库12c中，检索再授信确认标志被设定为开的预约信息中的再授信确认日为今天的预约信息（步骤S41）。接下来，系统控制部14选择检索出的预约信息中的1个（步骤S42）。接下来，系统控制部14判定选择的预约信息中是否设定了第2信用卡信息（步骤S43）。此时，系统控制部14在判定为没有设定第2信用卡信息的情况下（步骤S43：否），转入步骤S45。另一方面，系统控制部14在判定为设定了第2信用卡信息的情况下（步骤S43：是），针对与选择出的预约信息对应的预约，取消由预约时的授信确认确保的第2希望的信 用卡的授信（步骤S44）。进行该处理的原因是防止对1个预约确保多个授信额度。具体而言，系统控制部14根据选择的预约信息取得住宿费用认可编号。接下来，系统控制部14向结算服务器2发送授信取消请求，该授信取消请求包含取得的住宿费用认可编号作为认可编号。结算服务器2在接收到授信取消请求时，解除与授信取消请求中包含的认可编号对应的授信额度。此外，在从进行上次授信确认的日子起经过了授信期间的情况下，系统控制部14可以不取消授信。系统控制部14在结束步骤S45的处理后，转入步骤S45。 

在步骤S45中，系统控制部14作为确认单元，根据选择的预约信息中包含的第1信用卡信息，确认第1希望的信用卡的授信。该处理的内容与图7所示的与预约处理的步骤S4的处理内容基本相同。其中，系统控制部14将选择的预约信息中包含的第1信用卡信息设定于授信确认请求中。 

接下来，系统控制部14判定是否能够确认授信（步骤S46）。此时，系统控制部14在判定为不能够确认授信的情况下（步骤S46：否），转入步骤S51。另一方面，系统控制部14在判定为能够确认授信的情况下（步骤S46：是），利用在步骤S45中从结算服务器2接收到的授信确认响应中包含的认可编号来改写选择的预约信息中包含的住宿费用认可编号。接下来，系统控制部14选择的预约信息中包含的授信确认结果中设定“成功”（步骤S47）。 

接下来，系统控制部14判定选择的预约信息中包含的结算方法信息是否是“在线卡结算”（步骤S48）。此时，在判定为结算方法信息是“在线卡结算”的情况下（步骤S48：是），系统控制部14作为输出单元，发送在线卡结算通知邮件（步骤S49）。具体而言，系统控制部14从会员信息数据库12a中检索与选择的预约信息中包含的用户ID对应的会员信息。接下来，系统控制部14根据检索出的会员信息取得邮件地址。接下来，系统控制部14生成在线卡结算通知邮件。此时，系统控制部14将取得的邮件地址设定在在线卡结算通知邮件的地址中。此外，由于能够利用第1希望的信用卡确认授信，因此系统控制部14在在线卡结算通知邮件的正文中设定有表示结算方法不从在线卡结算变更为现场结算的语句。并且，系统控制部14发送生成的在线卡结算通知邮件。系统控制部14在结束步骤S49的处理后，转入步骤S57。 

另一方面，在判定为结算方法信息不是“在线卡结算”的情况下（步骤S48：否），系统控制部14作为输出单元，发送结算方法可恢复通知邮件（步骤S50）。具体而言， 系统控制部14生成结算方法可恢复通知邮件。此时，系统控制部14与步骤S49的情况同样地设定地址。此外，由于能够利用第1希望的信用卡确认授信，因此系统控制部14在结算方法可恢复通知邮件的正文中设定有表示能够从现场结算恢复到基于第1希望的信用卡的在线卡结算的语句。此外，系统控制部14在结算方法可恢复通知邮件的正文中设定有结算方法恢复认可页面的URL。系统控制部14在结算方法恢复认可页面的URL上，附加上选择的预约信息中包含的预约编号。并且，系统控制部14发送生成的结算方法可恢复通知邮件。系统控制部14在结束步骤S50的处理后，转入步骤S57。 

在接收到结算方法可恢复通知邮件的用户选择了正文中设定的URL时，用户终端4向住宿设施预约服务器1发送包含URL的请求，与此相应地，系统控制部14向用户终端4发送结算方法恢复认可页面。在此，用户在选择了认可按钮时，系统控制部14从预约信息数据库12c中检索与在接收到的请求中包含的URL上附加的预约编号对应的预约信息。接下来，系统控制部14将检索出的预约信息中包含的结算方法信息变更为“在线卡结算”。 

在步骤S51中，系统控制部14判定在选择的预约信息中是否设定了第2信用卡信息。此时，系统控制部14在判定为没有设定第2信用卡信息的情况下（步骤S51：否），转入步骤S55。另一方面，系统控制部14在判定为设定了第2信用卡信息的情况下（步骤S51：是），根据选择的预约信息中包含的第2信用卡信息，确认第2希望的信用卡的授信（步骤S52）。该处理的内容与步骤S45的处理内容基本相同。但是，系统控制部14在授信确认请求中设定有选择的预约信息中包含的第2信用卡信息。 

接下来，系统控制部14判定是否能够确认授信（步骤S53）。此时，系统控制部14在判定为不能够确认授信的情况下（步骤S53：否），转入步骤S55。另一方面，系统控制部14在判定为能够确认授信的情况下（步骤S53：是），利用在步骤S52中从结算服务器2接收到的授信确认响应中包含的认可编号改写选择的预约信息中包含的住宿费用认可编号。接下来，系统控制部14在选择的预约信息中包含的授信确认结果中设定“成功”。此外，系统控制部14在选择的预约信息中包含的利用卡类别中设定“第2卡”（步骤S54）。接下来，系统控制部14转入步骤S57。 

在步骤S55中，系统控制部14将选择的预约信息中包含的结算方法信息变更为 “现场结算”。此外，系统控制部14将选择的预约信息中包含的再再授信确认标志设定为关。 

接下来，系统控制部14作为输出单元，发送现场结算通知邮件（步骤S56）。具体而言，系统控制部14生成现场结算通知邮件。此时，系统控制部14与步骤S49的情况相同地设定地址。此外，系统控制部14在现场结算通知邮件的正文中设定有表示结算方法从在线卡结算变更为现场结算的语句。并且，系统控制部14发送生成的现场结算通知邮件。系统控制部14在结束步骤S56的处理后，转入步骤S57。此外，系统控制部14也可以对被预约的住宿设施的提供者发送现场结算通知邮件 

在步骤S57中，系统控制部14判定在步骤S41中检索出的预约信息中是否仍有未选择的预约信息。此时，系统控制部14在判定为仍有未选择的预约信息的情况下（步骤S57：是），选择仍未选择的预约信息中的1个（步骤S58）。接下来，系统控制部14转入步骤S43。系统控制部l4通过重复步骤S43～S58的处理，对需要本日再授信确认的各个预约进行再授信确认。并且，系统控制部14在判定为选择了全部预约信息的情况下（步骤S57：否），结束再授信确认处理。 

图10是示出本实施方式的住宿设施预约服务器1的系统控制部14的再再授信确认处理中的处理例的流程图。 

如图10所示，系统控制部14从预约信息数据库12c中，检索再再授信确认标志被设定为开的预约信息中的再再授信确认日为今天的预约信息（步骤S61）。接下来，系统控制部14选择检索出的预约信息中的1个（步骤S62）。接下来，系统控制部14针对与选择的预约信息对应的预约，取消由再授信确认确保的授信（步骤S63）。该处理的内容与图9所示的再授信确认处理的步骤S44的处理内容相同。 

接下来，系统控制部14判定选择的预约信息中包含的利用卡类别是否是“第1卡”（步骤S64）。此时，系统控制部14在判定为利用卡类别是“第1卡”的情况下（步骤S64：是），取得选择的预约信息中包含的第1信用卡信息（步骤S65）。接下来，系统控制部14转入步骤S67。另一方面，系统控制部14在判定为利用卡类别不是“第1卡”的情况下（步骤S64：否），取得选择的预约信息中包含的第2信用卡信息（步骤S66）。接下来，系统控制部14转入步骤S67。 

在步骤S67中，系统控制部14根据在步骤S65或S66中取得的信用卡信息，确认授信。该处理的内容与图7所示的与预约处理的步骤S4的处理内容相同。接下来， 系统控制部14判定是否能够确认授信（步骤S68）。此时，系统控制部14在判定为能够确认授信的情况下（步骤S68：是），利用在步骤S67中从结算服务器2接收到的授信确认响应中包含的认可编号来改写选择的预约信息中包含的住宿费用认可编号。接下来，系统控制部14转入步骤S71。 

另一方面，系统控制部14在判定为不能够确认授信的情况下（步骤S68：否），在选择的预约信息中包含的授信确认结果中设定“失败”。此外，系统控制部14将选择的预约信息中包含的结算方法信息变更为“现场结算”（步骤S69）。接下来，系统控制部14发送现场结算通知邮件（步骤S70）。该处理的内容与图9所示的再授信确认处理的步骤S56的处理内容相同。系统控制部14在结束步骤S70的处理后，转入步骤S71。 

在步骤S71中，系统控制部14判定在步骤S61中检索出的预约信息中是否仍有未选择的预约信息。此时，系统控制部14在判定为仍有未选择的预约信息的情况下（步骤S71：是），选择仍未选择的预约信息中的1个（步骤S72）。接下来，系统控制部14转入步骤S63。系统控制部14通过重复步骤S63～S72的处理，对需要本日再再授信确认的各个预约进行再再授信确认。并且，系统控制部14在判定为选择了全部预约信息的情况下（步骤S71：否），结束再再授信确认处理。 

图11是示出本实施方式的住宿设施预约服务器1的系统控制部14的可选费用登记处理中的处理例的流程图。 

在产生了可选费用的情况下，住宿设施的提供者操作住宿设施终端3来登记可选费用。此时，提供者输入可选费用、预约编号等。这样，住宿设施终端3向住宿设施预约服务器1发送可选费用登记请求。这样，在住宿设施预约服务器1接收到可选费用登记请求时开始可选费用登记处理。 

如图11所示，系统控制部14从预约信息数据库12c中检索与可选费用登记请求中包含的预约编号对应的预约信息。接下来，系统控制部14判定在检索出的预约信息中包含的结算方法信息中是否设定了“在线卡结算”，并且，判定在检索出的预约信息中包含的授信确认结果中是否设定了成功（步骤S81）。 

此时，在判定为在结算方法信息中没有设定“在线卡结算”的情况下、或者在判定为在授信确认结果中没有设定“成功”的情况下（步骤S81：否），系统控制部14向作为可选费用登记请求的发送源的住宿设施终端3发送授信确认错误结束页面（步 骤S82）。授信确认错误结束页面是显示表示不能够对可选费用确认授信的消息的Web页面。系统控制部14在结束步骤S82的处理后，结束可选费用登记处理。 

另一方面，当判定为在结算方法信息中设定了“在线卡结算”并且在授信确认结果中设定了成功的情况下（步骤S81：是），系统控制部14判定检索出的预约信息中包含的利用卡类别是否是“第1卡”（步骤S83）。此时，系统控制部14在判定为利用卡类别为“第1卡”的情况下（步骤S83：是），取得检索出的预约信息中包含的第1信用卡信息（步骤S84）。接下来，系统控制部14转入步骤S86。另一方面，系统控制部14在判定为利用卡类别不是“第1卡”的情况下（步骤S83：否），取得检索出的预约信息中包含的第2信用卡信息（步骤S85）。接下来，系统控制部14转入步骤S86。 

在步骤S86中，系统控制部14根据在步骤S84或S85取得的信用卡信息，确认用于结算可选费用的授信。该处理的内容与图7所示的与预约处理的步骤S4的处理内容基本相同。其中，系统控制部14替代住宿费用而在授信确认请求中设定可选费用。 

接下来，系统控制部14判定是否能够确认授信（步骤S87）。此时，系统控制部14在判定为不能够确认授信的情况下（步骤S87：否），转入步骤S82。另一方面，系统控制部14在判定为能够确认授信的情况下（步骤S87：是），将在步骤S86中从结算服务器2接收到的授信确认响应中包含的认可编号作为可选费用认可编号而设定在检索出的预约信息中。接下来，系统控制部14将检索出的预约信息中包含的可选费用结算标志设定为开。此外，系统控制部14在检索出的预约信息中设定可选费用登记请求中包含的可选费用（步骤S88）。接下来，系统控制部14向作为可选费用登记请求的发送源的住宿设施终端3发送授信确认正常结束页面（步骤S89）。授信确认正常结束页面是显示表示能够对可选费用确认授信的消息的Web页面。系统控制部14在结束步骤S89的处理后，结束可选费用登记处理。 

图12是示出本实施方式的住宿设施预约服务器1的系统控制部14的结算处理中的处理例的流程图。 

如图12所示，系统控制部14从预约信息数据库12c中，检索在结算方法信息中设定了“在线卡结算”的预约信息中的退房日的次日为今天的预约信息（步骤S9）。接下来，系统控制部14选择检索出的预约信息中的一个（步骤S92）。接下来，系统 控制部14判定选择的预约信息中包含的利用卡类别是否是“第1卡”（步骤S93）。此时，系统控制部14在判定为利用卡类别是“第1卡”的情况下（步骤S93：是），取得检索出的预约信息中包含的第1信用卡信息（步骤S94）。接下来，系统控制部14转入步骤S96。另一方面，系统控制部14在判定为利用卡类别不是“第1卡”的情况下（步骤S93：否），取得检索出的预约信息中包含的第2信用卡信息（步骤S95）。接下来，系统控制部14转入步骤S96。 

在步骤S96中，系统控制部14判定选择的预约信息中包含的可选结算标志是否被设定为开。此时，系统控制部14在判定为可选结算标志未被设定为开的情况下（步骤S96：否），根据取得的信用卡信息，结算选择的预约信息中包含的住宿费用（步骤S97）。具体而言，系统控制部14向结算服务器2发送结算请求。结算请求包含取得的信用卡信息、利用额和认可编号等。系统控制部14设定选择的预约信息中包含的住宿费用和住宿费用认可编号作为利用额和认可编号。结算服务器2在接收到结算请求时，进行如下处理：与结算请求中包含的认可编号对应地，由结算请求中包含的住宿费用确定从用户的账户中支取的利用费用。系统控制部14在结束步骤S97的处理后，转入步骤S99。 

另一方面，在判定为可选结算标志被设定为开的情况下（步骤S96：是），系统控制部14作为结算单元，根据取得的信用卡信息，结算包括在选择的预约信息中包含的住宿费用和可选费用在内的利用费用（步骤S98）。具体而言，系统控制部14利用与步骤S97相同的方法来结算住宿费用。此外，系统控制部14向结算服务器2发送设定了选择的预约信息中包含的可选费用和可选费用认可编号的结算请求。由此，系统控制部14结算可选费用。系统控制部14在结束步骤S98的处理后，转入步骤S99。 

在步骤S99中，系统控制部14判定在步骤S91中检索出的预约信息中是否仍有未选择的预约信息。此时，系统控制部14在判定为仍有未选择的预约信息的情况下（步骤S99：是），选择仍未选择的预约信息中的一个（步骤S100）。接下来，系统控制部14转入步骤S93。系统控制部14通过重复步骤S93～S100的处理，对需要本日结算的各个预约进行利用费用的结算。并且，系统控制部14在判定为选择了全部预约信息的情况下（步骤S99：否），结束结算处理。 

如上所述，根据本实施方式，住宿设施预约服务器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中构筑有授信确认历史数据库。在授信确认历史数据库中，登记有包含不能够确认授信的预约日在内的授信确认历史和包含在再授信确认中能够确认授信的日子在内的授信确认历史。更具体而言，在授信确认历史中，将预约编号、授信确认日、授信确认类别和信用卡公司信息相对应地进行登记。预约编号表示进行了授信确认的预约。授信确认日是不能够确认授信的预约日或者是能够确认授信的再授信确认日中的一个。授信确认类别是所进行的授信确认的类别。在授信确认类别中设定了“第1”或“第2”中的任意一个。“第1”表示预约时的授信确认。“第2”表示再授信确认。信用卡公司信息表示作为进行了授信确认的信用卡的发行方的信用卡公司。 

在图7所示的预约处理的步骤S8中，系统控制部14在判定为错误类别是“超过限额”的情况下（步骤S8：是），不执行步骤S10，执行步骤S11。在图8所示的结算方法变更预约处理中，系统控制部14在结束了步骤S28的处理后，作为存储控制单元，登记授信确认历史。具体而言，系统控制部14将预约日设定为授信确认日。此外，系统控制部14在授信确认类别中设定“第1”。此外，系统控制部14根据在存储部12中与请求预约的用户ID相对应地存储的卡信息，取得信用卡公司信息。并且，系统控制部14将包含新预约编号、再授信确认日、再授信确认类别和信用卡公 司信息在内的授信确认历史登记到授信确认历史数据库中。在图9所示的再授信确认处理的步骤S46中，系统控制部14在判定为能够确认授信的情况下（步骤S46：是），作为存储控制单元，登记授信确认历史。具体而言，系统控制部14根据选择的预约信息取得预约编号和再授信确认日。此外，系统控制部14在再授信确认类别中设定“第2”。此外，系统控制部14根据选择的预约信息中包含的第1信用卡信息，取得信用卡公司信息。并且，系统控制部14将包含预约编号、再授信确认日、再授信确认类别和信用卡公司信息在内的授信确认历史登记到授信确认历史数据库中。 

在结算方法变更预约处理的步骤S29中，系统控制部14不在再授信确认日中设定授信额度清除日。接下来，系统控制部14从授信确认历史数据库12中检索包含取得的信用卡公司信息的授信确认历史。接下来，系统控制部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。 

此外，在上述实施方式中，将本发明应用于住宿设施的提供。但是，只要是在预约时确定利用日的服务，就可以将本发明应用于任何服务。作为这样的服务，例如有高尔夫球场等竞技设施的提供、由飞机、火车、船舶、乘用车等交通设备实现的人的运输等。 

标号说明 

1 住宿设施预约服务器 

2 结算服务器 

3 住宿设施终端 

4 用户终端 

11 通信部 

12 存储部 

12a 会员信息数据库 

12b 住宿设施信息数据库 

12c 预约信息数据库 

13 输入/输出接口 

14 系统控制部 

14a CPU 

14b ROM 

14c RAM 

15 系统总线 

NW 网络 

S 信息处理系统 。

Claims (9)

1.一种信息处理装置，其特征在于，其具有：

预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；

确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及

输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。

2.根据权利要求1所述的信息处理装置，其特征在于，

在由所述预约单元接受了预约的服务的利用天数为与授予利用所述信用卡进行支付的信用的期间相应的授信天数以上的情况下，所述确认单元在接受了预约的服务的利用开始日的前一日之前，确认所述指定的信用卡的有效性。

3.根据权利要求2所述的信息处理装置，其特征在于，

该信息处理装置还具有第2确认单元，该第2确认单元在能够通过所述确认单元确认为有效后，在距离所述利用费用的结算日的天数为所述授信天数以下的日子以后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性，

所述输出单元在不能够通过所述第2确认单元确认为有效的情况下，输出表示将结算方法变更为与利用所述指定的信用卡进行的结算不同的方法的信息。

4.根据权利要求1～3中的任意一项所述的信息处理装置，其特征在于，

所述信息处理装置还具有结算单元，在除了能够通过所述确认单元确认有效性的所述利用费用以外、还因利用预约的服务而产生费用的情况下，该结算单元根据所述存储单元中存储的所述信息，利用所述指定的信用卡来结算包含所述产生的费用在内的所述利用费用。

5.根据权利要求1～4中的任意一项所述的信息处理装置，其特征在于，

所述信息处理装置还具有判定单元，该判定单元判定针对所述请求不能够确认所述指定的信用卡为有效的原因是否是所述利用费用超过所述指定的信用卡的可用额度，

所述预约单元在通过所述判定单元判定为所述原因是所述利用费用超过所述可用额度的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中。

6.根据权利要求1～5中的任意一项所述的信息处理装置，其特征在于，

所述信息处理装置还具有存储控制单元和推测单元，

所述存储控制单元将与所述请求对应的所述指定的信用卡的有效性的确认日和所述确认单元确认的有效性的确认日存储在确认日存储单元中，

所述推测单元根据所述确认日存储单元中存储的所述确认日，推测所述指定的信用卡成为有效的日子，

所述确认单元在由所述推测单元推测出的日子确认所述指定的信用卡的有效性。

7.一种由计算机执行的信息处理方法，其特征在于，所述信息处理方法包含：

预约步骤，针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；

确认步骤，在所述预约单元中接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及

输出步骤，在所述确认步骤中能够确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在所述确认步骤中不能够确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。

8.一种信息处理程序，其特征在于，该信息处理程序使计算机作为以下单元来发挥作用：

预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；

确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及

输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。

9.一种记录介质，其记录有计算机能读取的信息处理程序，该信息处理程序能够使计算机作为以下单元来发挥作用：

预约单元，其针对在服务的利用日以后利用信用卡来结算利用费用的预约请求，在不能够确认指定的所述信用卡的有效性的情况下，接受预约，并将所述指定的信用卡的信息存储到存储单元中；

确认单元，其在由所述预约单元接受了预约后，根据所述存储单元中存储的所述信息，确认所述指定的信用卡的有效性；以及

输出单元，其在能够通过所述确认单元确认所述指定的信用卡为有效的情况下，输出表示将结算方法设为利用所述指定的信用卡进行的结算的信息，在不能够通过所述确认单元确认为有效的情况下，输出表示将结算方法设为与利用所述指定的信用卡进行的结算不同的方法的信息。

Images