电子业务确认系统及其实现方法
技术领域
本发明涉及电子业务技术领域,更具体地,涉及电子业务确认系统及其实现方法。
背景技术
由于方便、成本低、跨地域等优点,电子业务正在全球飞速发展着。电子业务通常包括电子商务、移动商务、电子政务等各种表现形式。虽然目前电子业务发展得很快,但是由于电子业务的发生是在人不出现或者没有人的参与下自动完成的,这可能会引起一系列的安全问题。比如:在进行网上交易、网上支付等网上电子业务时,由于无法得到用户的物理签名,而只能根据用户名和密码来验证用户的身份,银行和商家很难保证进行网上交易、支付的人的身份合法性,这就给欺诈的产生提供了温床,并给银行、信用卡公司,商家和持卡人带来了巨大的经济损失。
根据权威调查统计:2003年美国信用卡欺诈损失为23.7亿美元,其中网上欺诈损失为12.3亿美元,2002年全球银行卡欺诈损失甚至达到38亿美元。再根据Lpsos-Insights,2004年1月统计:大约70%的用户害怕在互联网上用卡支付。
因此,迫切需要一种能够监控电子业务发生的通知与确认方式,并且这种方式是安全和方便的。比如,当银行帐户里的金额减少时,能够自动通知持卡人或授权监控人,只有收到被通知人的确认后,再准予进行转帐。另外,海关、货运、航空、订单、各种申请批复等一系列靠传统邮件、电话通知或者人们主动查询的系统,需要一种方式能够自动通知有关的人,并接收有关人的回应(确认)结果。
目前,在现有技术中有一种利用移动电话短消息通知电子业务中数据变化的方法。在这种方法中,当某些重要的数据,比如银行帐户里的金额发生变化时,业务发生系统通过移动电话网关向相关的人的移动电话发送短消息以进行通知,如果被通知的人觉察出有问题,则再进行电话查询等相应处理。在这种方法中,由于移动电话中仅仅显示短消息,并不对短消息进行进一步处理,因此这种方式并不能够控制业务的发生,至多只能在业务发生后了解到业务的发生,因此这种现有技术中无法监控电子业务,从而电子业务的安全性无法得到保证。
发明内容
有鉴于此,本发明的主要目的是提出一种电子业务确认系统,能够对电子业务的发生予以监控,从而提高电子业务的安全性。
本发明的另一目的是提出一种电子业务确认方法,能够对电子业务的发生予以监控,从而提高电子业务的安全性。
本发明的另一目的是提出一种电子业务确认中心,应用该中心能够对电子业务的发生予以监控,从而提高电子业务的安全性。
本发明的另一目的是提出一种确认终端,应用该确认终端能够实现对电子业务的发生予以监控,从而提高电子业务的安全性。
为达到上述目的,本发明的技术方案是这样实现的:
一种电子业务确认系统,该电子业务确认系统包括:
电子业务应用系统,用于当执行电子业务时向确认中心发送电子业务确认请求,并根据确认中心返回的电子业务确认结果对电子业务进行操作;
确认中心,用于根据所述电子业务确认请求确定对应的确认终端,向该确认终端发送电子业务确认消息,并将确认终端返回的电子业务确认结果发送到电子业务应用系统;
确认终端,用于接收电子业务确认消息,根据用户的反馈生成电子业务确认结果,并将所述电子业务确认结果发送到确认中心。
所述确认中心以短消息(SMS)协议、或Socket协议、或Datagram协议向确认终端发送所述电子业务确认消息。
所述确认终端为移动电话、PDA、PC、膝上型计算机。
所述电子业务应用系统为银行帐户监控系统、电话银行交易系统、网络银行交易系统、电子商务交易系统、流动资产监控系统、网络密码保护系统。
所述确认中心包括:
Web服务器,用于接收所述电子业务确认请求,控制应用服务器在数据库中查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并将确认终端发送的所述电子业务确认结果发送到电子业务应用系统;
应用服务器,用于根据Web服务器的命令查询数据库中的确认终端的ID和通信方式;
数据库,用于存储确认终端的ID以及所述电子业务确认消息和电子业务确认结果。
所述数据库进一步用于存储用户的个人信息;Web服务器进一步用于经由与确认终端的互联网Web连接接受用户注册,和/或,根据Web服务器的请求查询和/或修改用户的个人信息。
所述确认中心包括:
Socket服务器,用于接收所述电子业务确认请求,控制应用服务器在数据库中查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并将确认终端发送的所述电子业务确认结果发送到电子业务应用系统;
应用服务器,用于根据Socket服务器的命令查询数据库中的确认终端的ID;
数据库,用于存储确认终端的ID以及所述电子业务确认消息和电子业务确认结果。
所述确认终端注册的通信方式为:以SMS协议、或Socket协议、或Datagram协议与确认中心进行通信。
所述数据库进一步用于存储用户的个人信息;Socket服务器进一步用于经由与确认终端的互联网Socket连接接受用户注册,和/或,根据Socket服务器的请求查询和/或修改用户的个人信息。
所述确认终端包括电子业务确认模块,所述电子业务确认模块用于根据所述电子业务确认消息以及用户反馈生成电子业务确认结果。
一种电子业务确认中心,该电子业务确认中心接收由电子业务应用系统发送的电子业务确认请求,并根据电子业务确认请求查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并发送确认终端返回的电子业务确认结果到电子业务应用系统,该确认中心包括:
信息传输服务器,用于接收所述电子业务确认请求,控制应用服务器在数据库中查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并将确认终端发送的所述电子业务确认结果发送到电子业务应用系统;
应用服务器,用于根据信息传输服务器的命令查询数据库中的确认终端的ID和通信方式;
数据库,用于存储确认终端的ID以及所述电子业务确认消息和电子业务确认结果。
所述确认终端注册的通信方式为:以SMS协议、或Socket协议、或Datagram协议与所述确认中心进行通信。
所述信息传输服务器为Web服务器或Socket服务器。
一种移动终端,该移动终端用于从电子业务确认中心接收电子业务确认消息,并根据用户反馈生成将电子业务确认结果,以及将电子业务确认结果发送到电子业务确认中心,该移动终端包括具有收发电子业务确认信息的通信模块和电子业务确认模块,
通信模块,用于接收电子业务确认消息,并将电子业务确认模块生成的电子业务确认结果以发送到电子业务确认中心;
电子业务确认模块,用于根据所述电子业务确认消息以及用户反馈生成电子业务确认结果。
所述通信模块以SMS、或超文本传输协议(HTTP)的方式将所述电子业务确认结果发送到电子业务确认中心。
所述移动终端为移动电话、PDA。
所述电子业务确认模块,是以PUSH的方式被设置在所述移动终端中,或者以OTA的方式被设置在所述移动终端中。
一种电子业务确认方法,该方法包括:
A、电子业务应用系统当执行电子业务时向确认中心发送电子业务确认请求;
B、确认中心根据所述电子业务确认请求查找与该确认请求所对应的确认终端,并向确认终端发送电子业务确认消息;
C、确认终端向用户提示电子业务确认消息,根据用户的反馈生成电子业务确认结果,并将电子业务确认结果发送到确认中心;
D、确认中心将确认终端返回的电子业务确认结果发送到电子业务应用系统,电子业务应用系统根据该电子业务确认结果对电子业务进行操作。
该方法包括,进一步预先在电子业务应用系统中设定电子业务确认触发条件,步骤A为:电子业务应用系统在执行电子业务时,当满足所述电子业务确认触发条件时,向确认中心发送电子业务确认请求。
所述确认中心向确认终端发送电子业务确认消息为:确认中心向确认终端发送经过加密的电子业务确认消息。
所述确认中心向确认终端发送电子业务确认消息为:确认中心以确认终端注册的通信方式向确认终端发送电子业务确认消息。
步骤D所述电子业务应用系统对电子业务进行操作包括:电子业务应用系统根据电子业务确认结果判断是否准许执行电子业务,如果是,则执行,否则不执行电子业务。
从上述技术方案中可以看出,在本发明中,电子业务确认系统包括电子业务应用系统、确认中心和确认终端。确认终端根据用户的反馈生成电子业务确认结果,并将电子业务确认结果发送到确认中心;确认中心将电子业务确认结果发送到电子业务应用系统;然后电子业务应用系统根据电子业务确认结果来对电子业务的执行情况进行处理。因此,应用本发明以后,通过电子业务应用系统、确认中心和确认终端的上述交互,能够对电子业务的发生予以及时监控,而不只是在电子业务完成后才进行简单的通知,所以本发明极大地提高了电子业务的安全性。
附图说明
图1为根据本发明的电子业务确认系统的示范性结构示意图。
图2为根据本发明实施例的确认中心的示范性结构示意图。
图3为根据本发明实施例的电子业务确认系统的示范性结构示意图。
图4为根据本发明的电子业务确认方法的示范性流程示意图。
图5为根据本发明实施例的电子业务确认业务的示意图。
图6为根据本发明实施例的用户注册电子业务确认通知的方法流程示意图。
图7为根据本发明实施例的用户测试电子业务确认通知的方法流程示意图。
图8为根据本发明实施例的用户绑定电子业务确认通知的方法流程示意图。
图9为根据本发明实施例的用户UCD示意图。
图10为根据本发明实施例的确认中心UCD示意图。
图11为根据本发明实施例的电子业务应用系统UCD示意图。
具体实施方式
为使本发明的目的、技术方案和优点表达得更加清楚明白,下面结合附图及具体实施例对本发明再作进一步详细的说明。
图1为根据本发明实施例的电子业务确认系统的示范性结构示意图。如图1所示,该电子业务确认系统,包括:
电子业务应用系统101,用于当执行电子业务时向确认中心102发送电子业务确认请求,并根据确认中心102返回的电子业务确认结果对电子业务进行操作;
确认中心102,用于根据所述电子业务确认请求确定对应的确认终端103,向该确认终端103发送电子业务确认消息,并将确认终端103返回的电子业务确认结果发送到电子业务应用系统101;
确认终端103,用于接收电子业务确认消息,根据用户的反馈生成电子业务确认结果,并将所述电子业务确认结果发送到确认中心102。
其中,确认中心102可以通过SMS协议、Socket协议、Datagram等协议向确认终端发送电子业务确认消息。确认终端103返回的电子业务确认结果可以利用以SMS、或超文本传输协议(HTTP)等方式发送到电子业务应用系统101。在这里,本领域技术人员可以意识到:以上虽然罗列出一些具体的协议和实现方式,但本发明对确认中心102向确认终端发送电子业务确认消息的方式,以及确认终端103向电子业务应用系统101发送电子业务确认结果的方式并无限定。优选地,确认终端103可以首先在确认中心102注册相应的通信方式,然后再根据该通信方式实现相互通信。
其中,电子业务应用系统101可以为任意的电子业务运行系统或者电子业务操作系统,具体可为:银行帐户监控系统、电话银行交易系统、网络银行交易系统、电子商务交易系统、流动资产监控系统、网络密码保护系统等。具体地,网络密码保护系统可以为各种形式的电子邮件系统、网络游戏系统等。因此,应用本发明以后,还能够为电子邮件、网络游戏等提供进一步的保护,以防止非法登陆。
确认终端103可以为移动电话、个人数字助理(PDA)、个人计算机(PC)、膝上型计算机等具有通信功能的实体。
具体地,确认终端103包括具有收发电子业务确认信息的通信模块,还包括电子业务确认模块,电子业务确认模块用于根据所述电子业务确认消息以及用户反馈生成电子业务确认结果。在这里,电子业务确认模块可以是运行在确认终端103上的JAVA程序。优选地,可以将该JAVA程序(MIDlet)通过OTA(Over-The-Air)等远程设置的方式下载并自动安装到确认终端102上。确认终端102的JAVA程序平时不需启动,当需要执行确认时,确认中心102用Push Registry的方式将其激活。
Push Registry是MIDlet 2.0新增加的功能。是一种可以使MIDlet能够被服务器端的连接或者定时器激活的新机制。这种技术能够实现当某个事件发生时,不需要用户的介入,从服务器端让运行在移动终端上的MIDlet自动启动。
本发明中,确认终端103上的JAVA程序向其上的AMS(ApplicationManagement Software)注册可以被6000口上SMS通信协议的连接激活。(sms://:6000)。接到来自电子业务应用系统101的确认请求后,确认中心102向相应的确认终端103上的6000口上发送短消息。当JAVA程序被6000口上的短消息激活,开始启动,接收并处理短消息。
在以上过程中,虽然以JAVA语言为例详细说明了如何实现确认终端的功能,但是本领域技术人员可以意识到,本发明并不局限于JAVA语言,而是可以适用到各种面对对象的编程语言。比如,C语言,C++语言,PASCAL语言等。
确认中心102是整个系统的核心,用于为电子业务应用系统101提供确认服务。当确认中心102收到电子业务应用系统101的确认请求后,确认中心102向相应的确认终端103发出确认请求,当确认中心102收到来自确认终端103的确认结果后,把确认结果通知相应的电子业务应用系统101。
图2为根据本发明实施例的确认中心的示范性结构示意图。如图2所示,确认中心包括:
Web服务器201,用于接收所述电子业务确认请求,控制应用服务器202在数据库203中查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并将确认终端发送的所述电子业务确认结果发送到电子业务应用系统;
应用服务器202,用于根据Web服务器的命令查询数据库203中的确认终端的ID和通信方式;
数据库203,用于存储确认终端的ID以及所述电子业务确认消息和电子业务确认结果。
在这里,Web服务器201还可以用于经由与确认终端的互联网Web连接接受用户注册确认服务,和/或,根据Web服务器的请求在数据库203中查询和/或修改用户的个人信息。用户从可以从Web服务器201下载JAVA程序到确认终端上。另外,Web服务器201通过应用服务器202存储来自电子业务应用系统101的通知请求和来自确认终端103的确认结果到数据库203。
在这里,还可以用Socket服务器来替代Web服务器。此时,Socket服务器经由与确认终端103的互联网Socket连接接受用户注册,和/或,根据Socket服务器的请求查询和/或修改用户的个人信息。
具体地,应用服务器202处理来自Web服务器的请求,如查询/修改用户的个人信息,存储来自电子业务应用系统的通知请求和来自确认终端的确认结果等。数据库203中存储整个系统中的各种信息,比如用户的个人信息、来自电子业务应用系统101的通知请求和来自确认终端103的确认结果等。
以上虽然具体描述了确认中心的结构,但是本领域普通技术人员可以意识到,本发明并不局限于此。比如,可以采用既支持Web又支持Socket的服务器作为确认中心的对外接口,只要其支持基于互联网和移动通信的信息传输即可。
也就是说,通常确认中心包括:信息传输服务器,用于接收电子业务确认请求,控制应用服务器在数据库中查找对应的确认终端,以确认终端注册的通信方式向所述确认终端发送电子业务确认消息,并将确认终端发送的所述电子业务确认结果发送到电子业务应用系统;应用服务器,用于根据信息传输服务器的命令查询数据库中的确认终端的ID和通信方式;数据库,用于存储确认终端的ID以及所述电子业务确认消息和电子业务确认结果。
结合图1和图2,图3为根据本发明实施例的电子业务确认系统的示范性结构示意图。其中移动终端可以根据其所包含的浏览器在确认中心的WEB服务器中注册电子业务确认服务。当注册完电子业务确认服务后,移动终端便能够监控电子业务的发生。
图4为根据本发明的电子业务确认方法的示范性流程示意图。如图4所示,该方法包括:
步骤401:电子业务应用系统当执行电子业务时向确认中心发送电子业务确认请求;
步骤402:确认中心根据电子业务确认请求确定与该确认请求所对应的确认终端,并向确认终端发送电子业务确认消息;
步骤403:确认终端向用户提示电子业务确认消息,根据用户的反馈生成电子业务确认结果,并将电子业务确认结果发送到确认中心;
步骤404:确认中心将确认终端返回的电子业务确认结果发送到电子业务应用系统,电子业务应用系统根据该电子业务确认结果对电子业务进行操作。
以上过程中,可以预先在电子业务应用系统中设定电子业务确认触发条件,然后电子业务应用系统在执行电子业务中,只有当满足所述电子业务确认触发条件时,才向确认中心发送电子业务确认请求,当不满足电子业务确认触发条件,并不执行确认请求操作。
其中,确认中心向确认终端发送的电子业务确认消息优选是加密的,并且确认中心优选以短消息形式向确认终端发送电子业务确认消息。电子业务应用系统收到电子业务确认结果后,判断电子业务确认结果是否准许执行电子业务,如果是,则执行,否则不执行电子业务。
图5为根据本发明实施例的用户注册电子业务确认通知的方法流程示意图。此处假设该电子业务为网上银行模式中的一次转帐。
首先使用电子业务应用系统进行一次交易,电子业务应用系统根据用户事先设定的条件判断这次交易是否需要通知用户确认,如果这次交易不需要通知用户,则按现有的方式完成;如果这次交易需要用户的确认,电子业务应用系统生成通知信息,并向确认中心发送确认请求。确认中心首先将确认请求暂存到数据库中,然后根据确认请求中的ID,找到对应的确认终端。(此处确认请求中的ID和确认终端可以在注册时已经绑定在数据库中),然后将确认信息以短消息的形式发给对应的确认终端。然后,确认终端上的JAVA程序被短消息激活,开始运行,具体为:显示确认请求信息,并等待用户的确认,然后根据用户的确认结果,生成确认结果信息,并把确认结果信息送到确认中心。确认中心再更新数据库中对应的确认请求记录,并把确认结果送给电子业务应用系统,然后电子业务应用系统根据确认结果,完成或者拒绝用户所做的交易。
下面对用户注册电子业务确认通知的方法进行说明。图6为根据本发明实施例的用户注册电子业务确认通知的方法流程示意图。
如图6所示,首先,用户可以通过浏览器登录到确认中心的网站,选择有效的ID、设定密码、提供移动终端号码等个人信息、然后提交注册。当注册成功后,确认中心发送下载JAVA程序的信息给对应的移动终端。如果用户的移动终端上没有该JAVA程序,则根据下载信息的提示,自动下载并自动安装该JAVA程序到移动终端上。如果用户的移动终端上已经安装了该JAVA程序,则完成注册。
下面对用户测试电子业务确认通知的方法进行说明。图7为根据本发明实施例的用户测试电子业务确认通知的方法流程示意图。
如图7所示,首先用户通过浏览器登录到确认中心的网站,生成测试JAVA程序信息,然后确认中心发送该测试JAVA程序信息给用户的移动终端,用户对该测试JAVA程序信息进行确认,然后用户通过浏览器从确认中心的网站查看确认结果来了解测试是否成功。
下面对用户绑定电子业务确认通知的方法进行说明。图8为根据本发明实施例的用户绑定电子业务确认通知的方法流程示意图。
如图8所示,用户可以通过打电话、上网或者其它方式进入电子业务应用系统,将ID和电子业务应用系统的帐户绑定起来;例如:在电子银行系统中,将ID和银行帐号进行绑定。然后,用户设置确认电子业务确认触发条件,以完成绑定。例如:当一次从帐户中转帐达到100元或者一天内累计转帐达到200元时,需要通知户主并等待户主的确认,在其它情况下,则不需要通知户主。
图9为根据本发明实施例的用户UCD示意图;图10为根据本发明实施例的确认中心UCD示意图;图11为根据本发明实施例的电子业务应用系统UCD示意图。
下面详细描述本发明的一个实例。以电子银行系统中电子业务通知系统保护流动资产为例,描述本发明的完整流程。
首先假定:银行名称为:银行1,并且用户1在银行1开有帐户。此处银行1已经建立了确认中心,并把确认中心接口程序和电子银行系统集成在一起。
第一步:用户1到银行1的确认中心网站注册使用确认服务。
在这里,用户提供移动终端号码等个人信息,自己选择一个有效的ID,此ID与该用户的移动终端号码相对应,确认中心存储此ID和移动终端号码的对应关系。
第二步:用户1注册成功后,确认中心给用户1的移动终端发送一个下载JAVA程序的信息,此JAVA程序用于根据用户的反馈生成电子业务确认结果,并将电子业务确认结果发送到确认中心。其中,如果用户1的移动终端上没有该JAVA程序,则按照信息的提示,下载并自动安装该JAVA程序到用户1的移动终端上。如果用户1的移动终端上已经安装有该JAVA程序
则不需要再下载。
第三步:用户1到银行1的营业柜台或者打电话,将该ID与用户1在银行1的帐户绑定起来。并设定通知和确认条件。例如:当帐户里的金额一次减少达到100元或者一天内累计减少达到200元时,银行系统自动通知用户1,并等待用户1的确认结果。如果银行系统在一定时间内没有收到用户1允许的回应,则取消相应的减少帐户金额的操作。
第四步:用户1用银行1的帐户进行网上支付。
第五步:银行系统检查支付金额是否满足确认条件。如果不满足,则按现有的方式处理网上支付。如果满足条件,则生成通知和确认信息,并向确认中心发送确认请求。
第六步:确认中心根据该ID找到对应的移动终端号码,并把确认信息以短消息的形式发给相应的移动终端,并激活运行在移动终端上的JAVA程序。
第七步:用户1通过JAVA程序向确认中心发送确认结果,允许这次网上支付。
第八步:确认中心把允许支付的确认结果发给电子银行系统。
第九步:电子银行系统处理网上支付。
其中,如果第四步的网上支付请求不是用户1发出的,而是黑客等其它人发出的,则第七步中用户1能够对此进行及时监控,并可以通过JAVA程序向确认中心发送拒绝支付的确认结果,然后,确认中心将拒绝支付的确认结果发给电子银行系统,电子银行系统取消本次网上支付,从而能够杜绝非法电子业务,极大地提高电子业务的安全性。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。