基于服务器实时校验的IC卡验证装置和IC卡验证方法

摘要

本发明提供了一种基于服务器实时校验的IC卡验证装置，包括：刷卡信息获取模块，用于在用户刷卡时，利用刷卡设备获取刷卡信息；卡的有效性验证模块，用于基于所述刷卡信息获取模块获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；卡的业务逻辑验证模块，用于在所述卡的有效性验证模块对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证。本发明还提供了一种基于服务器实时校验的IC卡验证方法。通过本发明的技术方案，可以在现有的简单业务逻辑IC卡验证方式基础上，充分利用简单业务逻辑完成复杂业务逻辑的IC卡验证，建立复杂业务逻辑参与的多变业务逻辑IC卡验证的通用、统一验证思路。

权利要求

1.一种基于服务器实时校验的IC卡验证装置，其特征在于，包括：

刷卡信息获取模块，用于在用户刷卡时，利用刷卡设备获取刷卡信息；

卡的有效性验证模块，用于基于所述刷卡信息获取模块获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；

卡的业务逻辑验证模块，用于在所述卡的有效性验证模块对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证；

所述卡的业务逻辑验证模块，具体包括：

一次HTTP请求发送模块，用于在所述卡的有效性验证模块对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；

业务逻辑验证组件调用模块，用于后台服务器收到刷卡设备通过所述一次HTTP请求发送模块发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，所述卡的有效性验证模块还用于：当所述卡的有效性验证通过时，转向所述一次HTTP请求发送模块；当所述卡的有效性验证失败时，进行报警。

2.根据权利要求1所述的基于服务器实时校验的IC卡验证装置，其特征在于，所述卡的业务逻辑验证模块，具体还包括：一次HTTP响应返回模块，用于后台服务器将所述业务逻辑验证组件调用模块进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；

响应解析及执行模块，用于刷卡设备通过所述一次HTTP响应返回模块对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。

3.根据权利要求2所述的基于服务器实时校验的IC卡验证装置，其特征在于，所述响应解析及执行模块根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

4.根据权利要求1至3中任一项所述的基于服务器实时校验的IC卡验证装置，其特征在于，所述一次HTTP请求发送模块在所述卡的有效性验证模块对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

5.一种基于服务器实时校验的IC卡验证方法，其特征在于，包括：

步骤202：在用户刷卡时，利用刷卡设备获取刷卡信息；

步骤204：基于所述步骤202获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；

步骤206：在所述步骤204对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证；

所述步骤206，具体包括：

步骤302：在所述步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；

步骤304：后台服务器收到刷卡设备通过所述步骤302发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，所述步骤204还包括：当所述卡的有效性验证通过时，转向所述步骤302；当所述卡的有效性验证失败时，进行报警。

6.根据权利要求5所述的基于服务器实时校验的IC卡验证方法，其特征在于，所述步骤206，在所述步骤304之后，具体还包括：步骤306：后台服务器将所述步骤304进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；

步骤308：刷卡设备通过所述步骤306对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。

7.根据权利要求6所述的基于服务器实时校验的IC卡验证方法，其特征在于，所述步骤308根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

8.根据权利要求5至7中任一项所述的基于服务器实时校验的IC卡验证方法，其特征在于，所述步骤302在所述步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

说明书

基于服务器实时校验的IC卡验证装置和IC卡验证方法

技术领域

[0001] 本发明涉及门禁校验技术领域，具体地，涉及一种基于服务器实时校验的IC卡验证装置和一种基于服务器实时校验的IC卡验证方法。

背景技术

[0002] 门禁安全管理系统是新型现代化安全管理系统，它是解决重要部门出入口实现安全防范管理的有效措施。目前，越来越多的机要部门，如银行、宾馆、机房、军械库、机要室、办公间、智能化小区、工厂等都使用了门禁系统来管理出入安全。

[0003] 目前的门禁系统中，在处理IC卡验证时大部分使用的是单机异步验证方式。该方式是指卡的验证主要由刷卡器负责，并且这个验证过程是脱机完成的，用户刷卡时，刷卡信息存储在刷卡器内，每天在固定时间统一将当天的刷卡信息上传至服务器，从而完成各个刷卡点和服务器之间的信息同步。

[0004] 这个方案的缺点包括以下几个方面：

[0005] ⑴验证逻辑过于简单。由于验证逻辑是固化在刷卡器中的，所以只能处理简单的卡信息校验，不能处理复杂的业务逻辑。

[0006] ⑵不能应对多变的业务验证逻辑。对于越来越多的企业特别是工厂而言，希望通过IC卡来管理厂内车辆的路线，而校验逻辑根据不同的刷卡点而不同，并且这种业务逻辑存在经常更换的可能性。所以现行的验证方式不能满足客户的这种需求。

[0007] ⑶刷卡处理缺乏实时性。该方式采用的异步处理方式不能使管理者实时的监控各个刷卡点的刷卡情况。对于需要人工控制的刷卡点，只能人为的验证业务信息，人工控制门禁硬件（道闸等）。

[0008] 综合而言，很多工厂企业已不满足简单的门禁功能，更多要求将门禁控制和本企业业务联系起来，从而实现真正的厂内智能一卡通，这就使得刷卡验证过程具有实时性、验证逻辑复杂多变性等特点，而传统的单机异步验证方式已不能应对这种场景。

[0009] 智能IC卡管理要求刷卡处理过程具有以下特点：

[0010] 时效性高（需要实时监控刷卡过程，并且要求较快的刷卡响应时间）、安全性高。

[0011] 图4示出了现有技术中刷卡验证的流程图。如图4所示，现有的刷卡验证流程中，当用户刷卡后，刷卡设备获取卡信息，通过比对设备中存储的卡信息，从而对卡的有效性进行验证，若校验通过则执行放行操作，然后将此次刷卡记录在设备寄存器中。这部分验证过程是脱机完成的，并不需要和服务器交互。然后在固定时间与服务器通信，完成本时间段内的刷卡记录上传，并且同步服务器的卡务操作信息（下发新卡、注销旧卡等）。

[0012] 可以看出，现行的验证过程只能对卡本身的有效性进行验证，不能完成业务校验；而且服务器也不能实时的对刷卡过程进行监控。

[0013] 如前所述，对于企业提出的智能一卡通管控需求，就要求门禁系统可以更好的监控刷卡过程，以及应对业务逻辑的复杂多变。从而需要设计一种具有实时性，处理复杂校验逻辑的刷卡验证方法。使得刷卡过程可控，并且验证逻辑变更更加方便。需要为了解决这些问题而提出的一种新的解决方案。

[0014] 因此，需要一种新的基于服务器实时校验的IC卡验证技术，可以在现有的简单业务逻辑IC卡验证方式基础上，充分利用简单业务逻辑完成复杂业务逻辑的IC卡验证，建立复杂业务逻辑参与的多变业务逻辑IC卡验证的通用、统一验证思路。

发明内容

[0015] 本发明正是基于上述问题，提出了一种新的基于服务器实时校验的IC卡验证技术，可以在现有的简单业务逻辑IC卡验证方式基础上，充分利用简单业务逻辑完成复杂业务逻辑的IC卡验证，建立复杂业务逻辑参与的多变业务逻辑IC卡验证的通用、统一验证思路。

[0016] 有鉴于此，本发明提出了一种基于服务器实时校验的IC卡验证装置，包括：刷卡信息获取模块，用于在用户刷卡时，利用刷卡设备获取刷卡信息；卡的有效性验证模块，用于基于所述刷卡信息获取模块获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；卡的业务逻辑验证模块，用于在所述卡的有效性验证模块对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证。在该技术方案中，将刷卡验证分为两部分：一部分是在刷卡设备内部处理的卡的有效性验证、另一部分是由后台服务器负责处理卡的业务逻辑验证，通过这种采用后台服务器实时校验的方法对IC卡进行刷卡验证的方式，可以降低服务器响应压力并缩短刷卡响应时间。

[0017] 在上述技术方案中，优选地，所述卡的业务逻辑验证模块，具体包括：一次HTTP请求发送模块，用于在所述卡的有效性验证模块对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；业务逻辑验证组件调用模块，用于后台服务器收到刷卡设备通过所述一次HTTP请求发送模块发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，所述卡的有效性验证模块还用于：当所述卡的有效性验证通过时，转向所述一次HTTP请求发送模块；当所述卡的有效性验证失败时，进行报警。在该技术方案中，采用通过动态注册的方式与刷卡点灵活绑定的业务逻辑验证组件，不同的刷卡点根据其业务的不同实现自己的业务逻辑验证组件，当该刷卡点的业务发生变更时，可以动态的改变或扩展其业务逻辑验证组件，以解决业务验证多变问题，同时提高开发维护的效率。

[0018] 在上述技术方案中，优选地，所述卡的业务逻辑验证模块，具体还包括：一次HTTP响应返回模块，用于后台服务器将所述业务逻辑验证组件调用模块进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；响应解析及执行模块，用于刷卡设备通过所述一次HTTP响应返回模块对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。在该技术方案中，利用从HTTP协议支持客户/服务器模式、简单快速、灵活和无连接的特点，可以满足新刷卡验证方式对于网络传输的要求，改进现有的门禁系统中的单机异步的刷卡验证方式，变为联网实时验证的方式，实现刷卡复杂业务逻辑校验和管理层对刷卡过程的实时监控，可以应对刷卡业务复杂多变的应用场合。

[0019] 在上述技术方案中，优选地，所述响应解析及执行模块根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

[0020] 在上述技术方案中，优选地，所述一次HTTP请求发送模块在所述卡的有效性验证模块对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

[0021] 根据本发明的又一个方面，还提出了一种基于服务器实时校验的IC卡验证方法，包括：步骤202：在用户刷卡时，利用刷卡设备获取刷卡信息；步骤204：基于所述步骤202获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；步骤206：在所述步骤204对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证。在该技术方案中，将刷卡验证分为两部分：一部分是在刷卡设备内部处理的卡的有效性验证、另一部分是由后台服务器负责处理卡的业务逻辑验证，通过这种采用后台服务器实时校验的方法对IC卡进行刷卡验证的方式，可以降低服务器响应压力并缩短刷卡响应时间。

[0022] 在上述技术方案中，优选地，所述步骤206，具体包括：步骤302：在所述步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；步骤304：后台服务器收到刷卡设备通过所述步骤302发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，所述步骤204还包括：当所述卡的有效性验证通过时，转向所述一次HTTP请求发送模块；当所述卡的有效性验证失败时，进行报警。在该技术方案中，采用通过动态注册的方式与刷卡点灵活绑定的业务逻辑验证组件，不同的刷卡点根据其业务的不同实现自己的业务逻辑验证组件，当该刷卡点的业务发生变更时，可以动态的改变或扩展其业务逻辑验证组件，以解决业务验证多变问题，同时提高开发维护的效率。

[0023] 在上述技术方案中，优选地，所述步骤206，在所述步骤304之后，具体还包括：步骤306：后台服务器将所述步骤304进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；步骤308：刷卡设备通过所述步骤306对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。在该技术方案中，利用从HTTP协议支持客户/服务器模式、简单快速、灵活和无连接的特点，可以满足新刷卡验证方式对于网络传输的要求，改进现有的门禁系统中的单机异步的刷卡验证方式，变为联网实时验证的方式，实现刷卡复杂业务逻辑校验和管理层对刷卡过程的实时监控，可以应对刷卡业务复杂多变的应用场合。

[0024] 在上述技术方案中，优选地，所述步骤308根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

[0025] 在上述技术方案中，优选地，所述步骤302在所述步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

[0026] 通过以上技术方案，可以在现有的简单业务逻辑IC卡验证方式基础上，充分利用简单业务逻辑完成复杂业务逻辑的IC卡验证，建立复杂业务逻辑参与的多变业务逻辑IC卡验证的通用、统一验证思路。

附图说明

[0027] 图1示出了根据本发明的实施例的基于服务器实时校验的IC卡验证装置的框图；

[0028] 图2示出了根据本发明的实施例的基于服务器实时校验的IC卡验证方法的流程图；

[0029] 图3示出了根据本发明的实施例的卡的业务逻辑验证模块的流程图；

[0030] 图4示出了现有技术中刷卡验证的流程图；

[0031] 图5示出了基于本发明的实施例的基于服务器实时校验的IC卡验证装置的刷卡系统的部署图；

[0032] 图6示出了根据本发明的实施例的基于服务器实时校验的IC卡验证方法的详细流程图。

具体实施方式

[0033] 为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

[0034] 在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

[0035] 图1示出了根据本发明的实施例的基于服务器实时校验的IC卡验证装置的框图。

[0036] 如图1所示，根据本发明的实施例的基于服务器实时校验的IC卡验证装置100，包括：刷卡信息获取模块102，用于在用户刷卡时，利用刷卡设备获取刷卡信息；卡的有效性验证模块104，用于基于刷卡信息获取模块102获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；卡的业务逻辑验证模块106，用于在卡的有效性验证模块104对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证。在该技术方案中，将刷卡验证分为两部分：一部分是在刷卡设备内部处理的卡的有效性验证、另一部分是由后台服务器负责处理卡的业务逻辑验证，通过这种采用后台服务器实时校验的方法对IC卡进行刷卡验证的方式，可以降低服务器响应压力并缩短刷卡响应时间。

[0037] 在上述技术方案中，优选地，卡的业务逻辑验证模块106，具体包括：一次HTTP请求发送模块，用于在卡的有效性验证模块104对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；业务逻辑验证组件调用模块，用于后台服务器收到刷卡设备通过一次HTTP请求发送模块发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，卡的有效性验证模块104还用于：当卡的有效性验证通过时，转向一次HTTP请求发送模块；当卡的有效性验证失败时，进行报警。在该技术方案中，采用通过动态注册的方式与刷卡点灵活绑定的业务逻辑验证组件，不同的刷卡点根据其业务的不同实现自己的业务逻辑验证组件，当该刷卡点的业务发生变更时，可以动态的改变或扩展其业务逻辑验证组件，以解决业务验证多变问题，同时提高开发维护的效率。

[0038] 在上述技术方案中，优选地，卡的业务逻辑验证模块106，具体还包括：一次HTTP响应返回模块，用于后台服务器将业务逻辑验证组件调用模块进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；响应解析及执行模块，用于刷卡设备通过一次HTTP响应返回模块对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。在该技术方案中，利用从HTTP协议支持客户/服务器模式、简单快速、灵活和无连接的特点，可以满足新刷卡验证方式对于网络传输的要求，改进现有的门禁系统中的单机异步的刷卡验证方式，变为联网实时验证的方式，实现刷卡复杂业务逻辑校验和管理层对刷卡过程的实时监控，可以应对刷卡业务复杂多变的应用场合。

[0039] 在上述技术方案中，优选地，响应解析及执行模块根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

[0040] 在上述技术方案中，优选地，一次HTTP请求发送模块在卡的有效性验证模块对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

[0041] 图2示出了根据本发明的实施例的基于服务器实时校验的IC卡验证方法的流程图。

[0042] 如图2所示，根据本发明的实施例的基于服务器实时校验的IC卡验证方法，包括：步骤202：在用户刷卡时，利用刷卡设备获取刷卡信息；步骤204：基于步骤202获取的刷卡信息，在刷卡设备内部进行卡的有效性验证；步骤206：在步骤204对卡的有效性验证通过后，刷卡设备基于HTTP协议，通过后台服务器进行卡的业务逻辑验证。在该技术方案中，将刷卡验证分为两部分：一部分是在刷卡设备内部处理的卡的有效性验证、另一部分是由后台服务器负责处理卡的业务逻辑验证，通过这种采用后台服务器实时校验的方法对IC卡进行刷卡验证的方式，可以降低服务器响应压力并缩短刷卡响应时间。

[0043] 在上述技术方案中，优选地，如图3所示，步骤206，具体包括：步骤302：在步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送一次HTTP请求；步骤304：
后台服务器收到刷卡设备通过步骤302发送的一次HTTP请求后，调用后台注册的与该刷卡设备对应的刷卡点的业务逻辑验证组件，对与该一次HTTP请求对应的本次刷卡信息进行卡的业务逻辑验证；以及，步骤204还包括：当卡的有效性验证通过时，转向一次HTTP请求发送模块；当卡的有效性验证失败时，进行报警。在该技术方案中，采用通过动态注册的方式与刷卡点灵活绑定的业务逻辑验证组件，不同的刷卡点根据其业务的不同实现自己的业务逻辑验证组件，当该刷卡点的业务发生变更时，可以动态的改变或扩展其业务逻辑验证组件，以解决业务验证多变问题，同时提高开发维护的效率。

[0044] 在上述技术方案中，优选地，步骤206，在步骤304之后，具体还包括：步骤306：后台服务器将步骤304进行卡的业务逻辑验证所得卡的业务逻辑验证结果，作为基于一次HTTP请求的一次HTTP响应，返回给发送一次HTTP请求的刷卡设备；步骤308：刷卡设备通过步骤306对后台服务器发送的一次HTTP响应进行解析，根据解析结果进行后续处理。在该技术方案中，利用从HTTP协议支持客户/服务器模式、简单快速、灵活和无连接的特点，可以满足新刷卡验证方式对于网络传输的要求，改进现有的门禁系统中的单机异步的刷卡验证方式，变为联网实时验证的方式，实现刷卡复杂业务逻辑校验和管理层对刷卡过程的实时监控，可以应对刷卡业务复杂多变的应用场合。

[0045] 在上述技术方案中，优选地，步骤308根据解析结果进行后续处理的操作，具体包括：当解析结果为验证通过时则放行，当解析结果为验证不通过时则报警。

[0046] 在上述技术方案中，优选地，步骤302在步骤204对卡的有效性验证通过后，通过刷卡设备向后台服务器发送的一次HTTP请求，包括与刷卡设备对应的刷卡点信息和卡信息。

[0047] HTTP协议是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。该协议的特点可以概括如下：

[0048] ⑴支持客户/服务器模式。

[0049] ⑵简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

[0050] ⑶灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

[0051] ⑷无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

[0052] 从HTTP协议的这些特点可以看出，HTTP协议可以满足新刷卡验证方式对于网络传输的要求。

[0053] 使用了本发明的技术方案后，刷卡系统部署图如图5所示。

[0054] 如图5所示，在该刷卡系统中，刷卡设备充当了一个客户端的角色，刷卡过程中和服务器实时通信，将业务验证交给服务器完成。该过程是联网同步的。

[0055] 使用了本发明的技术方案后，刷卡验证的流程图如图6所示。

[0056] 如图6所示，该刷卡验证的流程包括：

[0057] ⑴用户刷卡后，刷卡设备获取刷卡信息。

[0058] ⑵首先进行卡有效性的验证，该验证过程和现行的验证方式相同，在刷卡设备内部进行。

[0059] ⑶有效性验证通过后，刷卡器（即刷卡设备）便向服务器发送一次HTTP请求，该一次HTTP请求包括刷卡点信息和卡信息。

[0060] ⑷服务器接收到刷卡器的刷卡请求后，调用后台注册的刷卡点对应的业务逻辑验证组件对本次刷卡信息进行业务验证。

[0061] ⑸服务器将本次业务验证结果作为HTTP响应返回给刷卡器。

[0062] ⑹刷卡器接收到响应结果后，根据验证结果进行响应的后续处理（验证通过则放行，验证不通过则报警）。

[0063] 在该刷卡验证的流程中，将刷卡验证分为两部分，一部分是卡的有效性验证，另一部分是卡的业务逻辑验证。卡的有效性验证放在刷卡器中处理，卡的业务逻辑验证则由后台服务器负责。该处理方式可以降低服务器响应压力并缩短刷卡响应时间（当该刷卡点没有业务校验时就只需要处理有效性验证即可）。

[0064] 在后台，业务逻辑验证组件通过注册的方式与刷卡点绑定，业务逻辑验证组件实现统一的接口。这样，当该刷卡点的业务发生变更时，可以动态的改变其业务逻辑验证组件，从而实现解决业务验证多变问题，同时使得开发维护的效率得以提高。

[0065] 下面通一个例子来说明本发明的开发、应用过程。

[0066] ⑴业务逻辑：IC卡需要先在A刷卡点刷完卡后才能在B刷卡点刷卡。

[0067] ⑵开发过程：

[0068] 根据定义好的业务校验接口，开发B刷卡点的业务校验组件；

[0069] 在刷卡点管理中注册B刷卡点校验组件；

[0070] 当业务逻辑发生变化后，只需更改业务校验组件，重新注册即可，减少了很大部分的开发量。

[0071] 本发明的技术方案，采用服务器实时校验的方法对IC卡进行验证，主要用于门禁IC卡刷卡时的复杂业务校验背景。本发明的技术方案，重点是改进现有的门禁系统中的单机异步的刷卡验证方式，变为联网实时验证的方式，实现了刷卡复杂业务逻辑校验，并实现了管理层对刷卡过程的实时监控，可以应对刷卡业务复杂多变的特点。

[0072] 本发明的技术方案，将刷卡验证分为刷卡器验证和服务器验证两部分，在保证实现复杂业务逻辑校验的同时可以减少刷卡的响应等待时间，并且在一定程度上减少了服务器压力；因为很多无效卡的刷卡动作在刷卡器验证阶段就被拦截，不会向服务器发送消息。

[0073] 本发明的技术方案，在处理服务器业务逻辑校验时采用的是统一的校验接口，不同的刷卡点根据其业务的不同实现自己的校验组件（即业务逻辑验证组件），采用动态注册的方式与刷卡点绑定；这种绑定是灵活的，当刷卡点业务发生改变时，只需更改注册的校验组件即可，不需要更改主要的刷卡处理过程，从而使系统具有很高的可扩展性。

[0074] 以上结合附图详细说明了本发明的技术方案，考虑到相关技术中没有简便的、统一的针对复杂业务逻辑IC卡验证的解决办法。现有的IC卡验证无法完成有复杂业务逻辑参与的多变业务逻辑IC卡验证过程。因此，本发明提出了一种基于服务器实时校验的IC卡验证装置和一种基于服务器实时校验的IC卡验证方法，可以在现有的简单业务逻辑IC卡验证方式基础上，充分利用简单业务逻辑完成复杂业务逻辑的IC卡验证，建立复杂业务逻辑参与的多变业务逻辑IC卡验证的通用、统一验证思路。

[0075] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。