专利名称：商务交易的确认系统和方法
技术领域：
本发明总的来说涉及电子商务，尤其涉及用于提供安全电子交易的一种系统和方法。更具体地，本发明涉及用于便于帐户持有者确认电子购物的一种方法和系统。
背景技术：
通过电子方法买卖的电子商务在现代社会生活中已经成为一件普通的事情。随着因特网(尤其是万维网)的普及，电子商务已经走向拥有计算机的任何人所在的家庭和办公室。由于多个原因，越来越多的人们将会选择在他们家里或者办公室的计算机上做生意(例如，购物)。例如，因为基于因特网的商务典型地提供了打折商品项目，所以把消费者吸引到因特网商务。此外，因特网一天24小时都能访问，从而方便了消费者的购物。
大多数消费者电子购物付费的主要方式是用信用卡。信用卡代表了持卡人一个预定的信用帐户。持卡人使用一张信用卡和商家进行电子交易。商家把购买请求(包括发送完整的信用卡号码)提交给信用卡公司，用于购买授权。信用卡公司授权或者否决和所述商家的信用卡交易。如果该购买得到批准，则从预定信用帐户里减掉所述购买的款数。
信用卡给卡持有者带来许多优点。例如，用信用卡的人花在银行以及为帐户收支平衡检查和储蓄所需的时间较少。此外，信用卡消除了携带大量现金的需求。而且，当使用信用卡时能自动进行购买批准，而支票或者现金定单的购买批准则被延误。所以，当通过电话或者邮件定单进行购买时，利用信用卡消除了与通过邮件发送支付款相联系的延误。
作为电子商务增长的一个后果，信用卡安全已经成为卡持有者主要的关注焦点。一些卡持有者由于担心他们的信用卡号码被截取或者被盗用，对利用信用卡进行网上购物非常谨慎。由于大多数因特网网页所用的超文本链接标示语言(HTML)采用了易受攻击的转发信息的方法，他们的担心是有道理的。为了解决因特网安全问题，一些商用网络使用了加密技术来保证网上交易的安全。这并没有给关心的消费者多少安慰，因为高智商的犯罪分子能够破解这些加密技术。此外，即使信用卡号码的传输是安全的，所述信用卡号码仍要储藏在接收方计算机上，并且可以通过闯入该计算机而被窃。此外，信用卡号码还可以由不诚实的侍者、保管员等使用的袖珍扫描仪等设备，直接从卡上盗取。
某些商务帐户(例如，支票帐户)提供了付款卡，如果没有增加的话它至少也面临同信用卡一样的安全风险。付款卡和信用卡类似，然而，为了完成借帐交易，在购买的时候除了卡号外，还必须给出卡持有者的个人识别号码(P1N)。此外，付款卡从与它相联系的帐户(典型的是支票帐户)中抽取资金。在大多数情况下，随同付款卡交易给出的PIN和被用来访问与所述付款卡相联系的帐户的PIN相同(例如，通过ATM机或者电话)。如果利用付款卡进行的交易被截取或者被盗用，则该盗窃者既能利用付款卡号码和PIN购物，又能直接从相关的借帐帐户上抽取资金。
对改善信用卡安全性的关注，促使信用卡公司和商家要提供保证安全电子交易的方法。例如，美国专利第6,012,144(Pickett)描述了维护因特网信用卡交易安全的一种方法，该方法是通过把信用卡号码分成两段，并把每段存储在一个或者多个服务器计算机的分离的数据存储设备上来实现的。该卡持有者决定信用卡号码的哪个部分将被发送到每个存储设备，并确定多个处理代码(口令)。处理代码以后可以通过自动电话呼叫从卡持有者那里获得，以便可以确认所述购买。这种方法有几个缺点。第一，Pickett的方法对卡持有者来说极其费时，因为信用卡号码没有被整个地发送给商家。相反，所述卡持有者必须分析该信用卡号码，并考虑出一个片段代码。此外，为了确认所述交易，卡持有者必须记住该片段代码，每次交易的片段代码可以不同。此外，提供安全软件的负担落在了所述商家的身上，他可能愿意或者不愿意提供这样一种系统。从而，如果卡持有者希望从没有这样一种系统的商家那去购买，则没有提供安全性。
美国专利第5,903,721(Sixtus)描述了用于提供改善信用卡交易安全性的一个替代方法。Sixtus的方法涉及卡持有者通过因特网购物。一个用于确认卡持有者的“信任服务器”，接收带有卡持有者的IP(因特网协议)地址的一个购买请求。如果由信任服务器接收的所述IP地址和该卡持有者的一个已注册的IP地址匹配，则确认该购买，并把它发往“信用票据交换所”，在那里批准或否决所述购买。在没有敏感的信用卡信息通过不安全的网络发送的同时，只有来自向信任服务器注册了IP地址的计算机的交易才能进行。此外，某些因特网服务提供商(ISP)使用动态IP寻址，其中，当用户登录该ISP网络时把一个暂时IP地址分配给他。从而，具有利用动态IP寻址的因特网服务提供商的卡持有者，不能使用由Sixtus讲授的交易安全系统。
举另一个例子，美国专利第5,991,738(Ogram)讲授了一个利用加密软件的方法。卡持有者希望从某个采用Ogram方法的商家那里购买物品，要从该商家的计算机中下载加密软件。该加密软件在发送给所述商家之前对任何敏感信息加密。Ogram方法的一个缺点是没有与卡持有者的安全购买确认处理。此外，所采用的加密技术在传输期间可以被截取和破解。
需要有用于提供安全和可靠的信用卡交易处理的系统和方法。也需要对商家是透明的、用于提供安全和可靠的信用卡交易处理的系统和方法。还需要有一个系统，便于卡持有者确认信用卡交易和提供卡持有者每个试图使用信用卡的提示通知。
发明内容
本发明通过提供一个用于提供安全可靠的对商家是透明的信用卡交易处理的系统和方法，解决与现有技术相联系的问题。本发明便于卡持有者在把一个批准信息发送给商家之前对每个信用卡交易确认，并把每个试图使用所述信用卡的提示通知提供给帐户持有者。
本发明公开了一个用于处理在帐户持有者和商家之间的商务交易的计算机系统，它包括一个处理单元，用来执行数据和代码，和一个存储器装置，用于存储数据和代码。所存储和执行的代码包括，一个商家通信模块，用于接收包括一个完整的帐户号码的交易批准请求，一个帐户持有者通信模块，用于为确认所述交易批准请求而便于和帐户持有者的单独连接，和一个授权模块，用来对所述交易批准请求作出响应，并用于只要所述帐户持有者的所述交易批准请求被确认的话，把一个批准信息发送给所述商家。
在一个特定的实施例中，所述授权模块包括一个交互确认模块，用来对接收的某个交易批准请求作出响应，并用于启动和帐户持有者的连接。在一个更具体的实施例中，所述计算机系统还包括一个网络接口，并且，所述交互确认模块主要用来通过该网络接口把一个电子消息发送给帐户持有者，并且还用于一旦接收到关于所发送的电子消息的答复，确认所述交易批准请求。
在另一个具体实施例中，所述计算机系统还包括一个远程通信装置，并且交互确认模块用来对帐户持有者发出一个自动电话呼叫，向帐户持有者复述交易批准请求的某一部分，并从帐户持有者那里接收确认指令。在一个更具体的实施例中，所述交互确认模块用来在复述交易批准请求的某一部分之前索取一个授权代码。
可选择的是，所述交互确认模块等待帐户持有者启动和系统的通信，或者，系统启动和帐户持有者的通信，以便确认待处理的交易批准请求。
在一个具体的实施例中，用来对来自帐户持有者的指令作出响应的授权模块，在还没有从帐户持有者输入的情况下，通过自动确认后继的交易批准请求，能选择性地禁止确认处理。
在另一个具体实施例中，授权模块包括一个主确认模块，如果帐户持有者在预先确认的时间周期过去之后还没有认可有关确认请求，则该主确认模块自动的放弃该确认请求。主确认模块还用来在确认请求被放弃时，向帐户持有者发送通知。
在另一个具体实施例中，一个交易批准请求包括一个来自第三方金融机构的确认请求，而授权模块用来将确认标记发送给该第三方金融机构。
本发明还公开了一种用于在帐户持有者和商家之间提供安全可靠的商务交易的方法。所述方法包括接收包括用来确认帐户持有者帐户完整帐户号码的一个交易批准请求，通过独立于商家的单独的通信，电子化地与该帐户持有者确认交易批准请求，只要该帐户持有者确认所述交易批准请求的话，还把一条批准信息发送给所述商家。
在一个具体方法中，用来同帐户持有者确认交易批准请求的步骤包括提醒帐户持有者确认所述交易批准请求。在一个更具体的方法中，提醒帐户持有者包括发送一条电子消息。在另一个更具体的方法中，用来确认所述交易批准请求的步骤包括接收对所述电子消息的答复。在另一个具体方法中，提醒所述帐户持有者包括向其发出一个自动电话呼叫，建立和所述帐户持有者的连接，至少复述交易批准请求的一个部分，以及从帐户持有者那里接收确认指令。在一个更具体的方法中，在复述所述交易批准请求至少一个部分之前证明所述帐户持有者属实。
另一个备选方法包括等待帐户持有者通过和所述计算机系统通信启动确认处理。在一个更具体的方法中，由帐户持有者通过网络或者电话连接启动确认，并且确认包括，通过网络或者通信设备接收来自帐户持有者的连接请求，建立和所述帐户持有者的连接，证明帐户持有者属实，向帐户持有者发送交易批准请求的至少一个部分，并且接收来自帐户持有者关于所述交易批准请求的确认指令。
帐户持有者能够随意地选择允许或者禁止所述确认处理。
在另一个具体方法中，电子确认所述交易批准请求的步骤包括，如果帐户持有者在预定的时间间隔内没有确认交易批准请求，则放弃所述交易批准请求。在一个更具体的方法中，当已经放弃所述交易批准请求时，向帐户持有者发送通知。
在另一个具体方法中，用来接收来自商家的一个交易批准请求的步骤包括，接收来自从所述商家那里接收交易批准请求的第三方金融机构的一个确认请求。把一个批准信息发送给所述商家的步骤包括把所述确认标志发送给所述第三方金融机构。
本发明也公开了用于预先确认的在商家和帐户持有者之间的某个交易的一个系统和方法。在一个具体的实施例中，一个计算机系统包括用于处理数据和代码的一个处理单元，以及用于存储数据和代码的一个存储装置。所述数据包括至少一条和帐户持有者有关的预先确认的标准。所述代码包括用于从商家那里接收交易批准请求的一个商家通信模块，和一个授权模块。所述授权模块将预先确认的的标准和交易批准请求进行比较，如果所述预先确认的的标准得到满足，则自动确认所述交易批准请求，由此消除这种必要，即在完成所述批准处理之前，获得帐户持有者的对所述交易批准请求的直接确认。
在某个具体实施例中，所述预先确认的标准包括与帐户持有者相关多个预先确认的标准，而如果所述预先确认的标准的任何一个得到满足，则所述交易批准请求得到确认。在一个可以替代的实施例中，直到全部的多个预先确认的标准得到满足才会自动确认所述交易批准请求。有用的预先确认的标准的例子包括但不局限于商家识别标识、交易数量(例如，购买价格)、交易日期、交易时间或者帐户持有者可能认为方便的任何其他的标准。可供选择的是，所述代码还包括一个卡持有者通信模块和/或一个用来便于帐户持有者对预先确认的标准进行修改的交互确认模块。在一个实施例中，所述预先确认的标准被这样初始设置，即直到所述帐户持有者修改所述预先确认的标准，才能够自动确认交易批准请求。作为另一个替代方案，所述初始预先确认的标准能够由帐户持有者删除(例如，当打开所述帐户时)。
参照下图描述本发明，其中，类似的参考编号赋给类似的成分。
图1是一个在按照本发明的卡持有者、个商家、信用卡公司和一个第三方确认公司之间的因特网的方框图，；图2是用来显示图1中信用卡公司的一个服务器的方框图，包括在所述工作存储器内的一个工作存储器和一个授权模块；图3是用来详细描述图2所示的授权模块的方框图；图4是用来显示用于在图2的信用卡批准请求队列中存储交易批准请求记录的示范数据结构的方框图；图5是用来显示用于在图2的卡持有者列表模块中存储卡持有者数据的示范数据结构的方框图；图6是用来显示用于在图2的购买历史模块中存储交易记录的示范数据结构的方框图；图7是用来总结用于按照本发明提供安全可靠的电子交易的一种方法的流程图；图8是用来总结用于执行图7所述方法的第4步骤(确认被禁止？)的一种方法的流程图；图9是用来总结用于执行图7所述方法的第5步骤(卡持有者确认)的一种方法的流程图；图10是用来总结用于执行图7所述方法的第5步骤(卡持有者确认)的一种替代方法的流程图；图11是按照本发明用来显示包括预先确认的标准的一个替代服务器和被用来预先确认的交易的一个替代授权模块的方框图；图12是用来详细描述图11所述的替代授权模块的方框图；图13是用来显示用于存储图11所述的预先确认的标准的示范数据结构的方框图；
图14是用来总结用于按照本发明提供安全可靠的电子交易的另一种方法的流程图；图15是用来总结用于执行图14所述方法的第5步骤(预先确认的标准得到满足？)的一种方法的流程图；图15A是用来总结用于执行图14所述的第5步骤(预先确认的标准得到满足？)的一种替代方法的流程图；图16是用来总结用于卡持有者修改与其帐户相联系的预先确认的标准的一种方法的流程图；具体实施方式
本发明通过给出一种新的系统和方法来解决与现有技术相关的问题，该系统和方法通过与帐户持有者确认每笔电子交易，提供安全可靠的电子交易。在下面的描述中，提出了大量的具体细节(例如，由信用卡公司处理的确认，由卡持有者发起的确认等等)以便给出关于本发明的一个透彻理解。然而，本领域的技术人员会认识到离开这些具体细节也可以实现本发明。在另外一些情形，忽略了一些众所周知的电子商务实践的细节(例如，电子信用请求/批准，计算机操作系统，通信软件等)，以便没必要把本发明弄得主次不清。
图1是用来显示一个系统100，它包括卡持有者102、商家104、信用卡公司106和一个第三方确认公司108，它们各自通过物理网络媒介112(1-4)(例如，电话线，同轴电缆等)与互连网络110(如因特网)相连。卡持有者102、商家104、信用卡公司106和确认公司108也通过另一个物理网络媒介114(例如电话线)进行通信。
卡持有者102拥有一个信用卡，通过信用卡的号码识别出由信用卡公司106提供的一个帐户。商家104提供卡持有者102利用信用卡号码通过互连网络110可以购买的商品和服务。卡持有者102通过提供完整的信用卡号码从商家104提出电子购买请求。该购买可以通过互连网络110，物理网络媒介114，或者甚至本人进行。作为对接收购买请求作出响应，商家104会把一个交易批准请求(TAR)提交给信用卡公司106。
接下来，在把一条批准或者否决的信息发布给商家104之前，所述TAR会经历两部分的核准。首先，所述购买请求由信用卡公司106进行标准的信用批准。在信用批准之后，将会要么由信用卡公司106，要么由确认公司108与卡持有者102确认所述购买请求。既可通过互连网络110也可通过物理网络媒介114实施确认。在确认之后，如果购买既由信用卡公司106批准又由卡持有者102确认，则通过物理网络媒介114或者互连网络110向商家104发送一条批准信息。
在该具体实施例中，一张信用卡简化了电子商务。然而，本领域的技术人员将会认识到本发明并不限于使用信用卡购物。可以和任何一种帐户类型(例如，付款卡)结合起来使用本发明，以便促进包括传输一个帐户号码的安全可靠的电子交易。在下面的描述中还会认识到，信用卡公司106执行所述的确认处理。然而，该确认处理可以由第三方确认公司108选择地执行。在这样一种实施例中，信用卡公司106把一个确认请求发送给确认公司108。确认公司108接着确认卡持有者102的所述交易请求，并把确认标志(指示该交易请求是否被确认，放弃等)回发给信用卡公司106。
图2是通过物理网络媒介112(3)连接到互连网络110上的一个服务器200(例如一个HTTP因特网服务器)的方框图。在该具体实施例中，服务器200是一个信用卡公司106的交易服务器，用于处理信用卡公司106的信用卡交易。服务器200包括一个处理单元(PU)202，一个网络接口204，一个系统总线206、非易失性存储器208、至少一个输入/输出(I/O)控制器210、一个系统时钟212、一个通信装置214和一个工作存储器216，以便使服务器200实现它想要的功能(例如，处理信用卡交易)。系统总线206使服务器200的各部分之间的通信更便利。
服务器200通过网络接口204在互连网络110上通信。网络接口204(例如，以太网适配卡)把数据包发到互连网络110上并从互连网络110中接收数据包，从而，让服务器200和卡持有者102通过互连网络110通信。非易失性存储器208(例如，只读存储器，或者一个或者多个硬盘驱动器)提供即使当服务器200关掉电源时也仍保持的数据和代码(例如，引导代码和程序)的存储。I/O控制器210为服务器200系统管理员管理用于用户接口器件(没有标出)的连接。I/O装置典型地包括键盘、鼠标、监视器、打印机和其他便于服务器200和管理员之间通信的装置。服务器200还包括用于维护正确日期和时间的一个系统时钟212，并按要求提供日期和时间数据。
服务器200还包括一个远程通信装置214(例如，一个调制解调器，或者电话)，用于在一个远端系统或者当事人和服务器200之间建立要么是数据要么是语音的连接。远端系统的例子包括由帐户持有者拥有的计算机102、商家104或者确认公司108。在一个具体实施例中，和卡持有者102的一个语音连接被用来确认待处理的TAR。
工作存储器216(例如，随机访问存储器)给服务器200提供动态存储器，并包括在系统启动期间被加载到工作存储器216的可执行代码(例如，操作系统218)。操作系统218使加载到工作存储器216中的所有其他模块的控制和执行便利。工作存储器216还包括信用批准请求队列(CARQ)220、卡持有者列表模块222、卡持有者通信模块224、授权模块226、确认待处理队列(VPQ)228、购买历史模块230和商家通信模块232。在启动时利用本领域的技术人员所熟知的方法初始化上面的每个模块和队列，并把他们从非易失性存储器208加载到工作存储器216。能够选择地把前面所述模块和队列从大量数据存储替代装置中加载到工作存储器216，这些存储替代装置包括，CD-ROM、磁带或者有大容量的可移动数据存储盘的驱动器(例如，Iomega的JazTM或ZipTM驱动器)，但也不限于此。
授权模块226控制和协调TAR的批准和确认。如上所述，在由第三方确认公司108处理确认的替代实施例中，授权模块226用来把用于确认的一个请求发送给确认公司108，并且，从确认公司108处接收确认标记。用于确认的被发送请求包括与所述购买请求有关的信息，诸如一个产品描述、购买价格、商家姓名或者任何其他有助于识别卡持有者交易的确认信息。例如，所接收的确认标记将会包括一个表示由所述卡持有者已经确认或者放弃的具体交易的一个代码。可供选择是，作为对由卡持有者102给出的指令的反应，授权模块还选择性地禁止所述确认处理(例如，自动地确认每个交易或者某个具体商家的交易)。卡持有者102一般地将会通过一个安全网络(例如，通过电话或者邮件)启动禁止所述确认处理的指令。
商家通信模块232通过网络接口204或者远程通信装置214从商家104那里接收TAR，并且把批准或者否决信息发送给他。卡持有者通信模块224通过互连网络110或者物理网络媒介114管理在服务器200和卡持有者102之间的通信。卡持有者列表模块222是一个数据库，用于存储信用卡公司106的当前客户(包括卡持有者102)的个人信息和帐户信息。本领域的技术人员将会理解到该卡持有者列表模块222会是一个典型的超大文件。因此，当在存储器216中显示卡持有者列表模块222时，应该理解到所述整个客户文件可能被存储在大数据存储系统中，诸如，非易失性存储器208，所述整个列表的一些部分将在必要时被交换进持有者列表222或者从其中交换出去。
信用卡批准请求队列(CARQ)220提供用于等待授权模块226的常规的信用批准的处理的TAR的存储。商家通信模块232周期性地查问网络接口204和远程通信装置214，以便确定是否存在来自商家104的任何引入的TAR，并把任何这样的请求转发给CARQ 220。
确认待处理队列(VPQ)228提供用于待处理由卡持有者102确认的TAR的存储。在所述TAR被确认与一个有效帐户对应，并通过常规的信用批准之后，授权模块226从CARQ 220把TAR转发到VPQ 228。TAR保持在VPQ228，直到被确认、否决或者直到过了预定的时间周期。
一旦一个TAR得到批准或者被否决，将会把所述TAR的一条记录转发给购买历史模块230。购买历史模块230存储一个预定时间周期(例如，30天一个周期)的先前帐户活动的信息。一旦超过把所述交易的一个书面记录(例如一个票据，或者一个电子票据等)传达给卡持有者102所述预定时间周期，就会把每个过期的TAR从工作存储器216转发到一个更长久的存储介质(例如，磁带)。
图3显示了授权模块226的方框图，包括信用批准模块302、主确认模块304、交互确认模块306和商家响应模块308。信用批准模块302利用本领域的技术人员所熟知的方法对在CARQ 220中存储的每个TAR执行常规信用批准处理。主确认模块304协调所述授权和确认处理，并且，负责授权模块226的所有控制。交互确认模块306完成卡持有者102的确认。商家响应模块308通过发送要么交易批准要么交易否决的信息启动和商家104的最终的通信。
图4显示了一个适用于本发明的具体实施例使用的一个信用批准请求数据结构400的例子。本领域的技术人员就会把数据结构400识别为一个链接表记录402(1-n)。记录402(1-n)中每个代表一个待处理TAR，并且包括一个完整的信用卡号码404，一个购买说明406，一个购买价格408，商家信息410，购买日期和时间信息412，一个被确认的标志414，一个确认被启动的标志415，一个被批准标志416，一个被否决的标志418和一个指针420。服务器200从具有所述TAR的商家那里接收完整的信用卡号码404、一个购买说明406、购买价格408、商家信息410和购买日期和时间信息412。使用被确认的标志414，被批准标志416，和被否决的标志418来表示在所述授权处理中的每个记录402的状态，下面将更详细地对这一点进行描述。指针420表示在所述表中的下一个记录402(+1)的存储器地址。最后一个记录402(n)包括表值422的结束，它表示在所述表中的最后一个记录。
被确认的标志414、确认被启动的标志415、被批准标志416和被否决的标志418是表示各自记录状态的单个比特标志。被确认的标志414表示所联系的TAR是否已经被确认(例如，被确认标志414＝1)或者所述TAR是否没有被确认(例如，被确认标志414＝0)。确认被启动标志415表示服务器200是否已经启动了对卡持有者102的所述确认处理。被批准标志416表示所述相关的TAR是否已经被批准(例如，被批准标志＝1)。被否决的标志418表示所述相关TAR是否已经被否决(例如，被否决标志＝1)。
图5显示了一个卡持有者数据结构500的一个例子，该数据结构适用于在卡持有者列表模块222中存储卡持有者数据。本领域的技术人员将会认识到数据结构500是记录502(1-n)的一个链接表，每一个记录502用于由信用卡公司106提供的一个有效信用帐户。每个记录502包括发布给相关卡持有者的一个完整信用卡号码504、一个个人识别号码(PIN)506、卡持有者信息508、联系信息510、信贷限额512、一个确认被请求的标志514、一个启动确认标志516和一个指针518。
PIN 506是用于在确认处理期间证实卡持有者102，或者允许卡持有者102设定参考设置(例如，确认被请求标志514，启动确认标志516等)的代码。卡持有者信息508包括但不限于诸如这样一些个人信息卡持有者的姓名、出生日期、社会保险号码和/或地址。联系信息510包括和卡持有者相关的用于通信的必要信息，尤其是用于TAR的确认信息。联系信息510可能包括但不限于电话号码、寻呼机号码或者电子邮件地址。信贷限额512表示相关的卡持有者预定的信贷限定额度。确认被请求标志514容许卡持有者102，例如在没有来自卡持有者102进一步输入的情况下，通过自动确认后继的TAR，有选择性地禁止确认处理。在该实施例中，确认被请求标志514是单个比特的标志，其中，数值1表示应该完成确认处理，而数值0表示所述卡持有者希望延缓确认处理。单个比特启动确认标志516表示卡持有者是否希望服务器200启动确认处理，或者服务器200是否应该等待用户102启动确认处理。如果启动确认标志516具有的值是1，交互确认模块306就启动相关的卡持有者的确认处理(例如，电子邮件，自动电话呼叫等)。如果启动确认标志516的数值是0，则相关的卡持有者必须启动确认处理(例如，向服务器发出电话呼叫，通过互连网络登录服务器200等)。指针518表示在卡持有者数据结构500中的下一个记录502中的起始地址。列表结尾指示520表示在卡持有者数据结构500中该记录502(n)是最后一个记录。
图6显示了适用于本发明的具体实施例的使用的购买历史数据结构600的例子。购买历史数据结构600是记录602(1-n)的链接列表，它的每一个记录包括完整的信用卡号码604、购买信息606、购买价格608、商家信息610、确认日期和时间信息612以及指针614。信用卡号码604让具体交易和相关的卡持有者一致。购买信息606包括有助于识别和卡持有者交易的信息(例如，产品说明书)。购买价格608表示与购买相关的费用。商家信息610识别提交TAR的商家。指针614表示在数据结构600中的下一个记录602的地址。列表结尾指示符616(n)表示在购买历史数据结构600中记录602(n)是最后一个记录。
本领域的技术人员将会懂得如上所述的信用批准请求数据结构400，卡持有者数据结构500和购买历史数据结构600实际上是示范性的，并且可能会，在本发明中采用其他的数据结构。因此，用举例的方法在此描述的具体数据结构不被认为是本发明的实质性要素。
现在参照图1-6说明本发明的一个具体实施例的操作。当卡持有者102向商家104提交一份商品或服务的定单，并且作为付款的手段使用由信用卡公司106分配的信用卡号码时，就开始了处理。商家104接着把包括由卡持有者102提供的信用卡号码、购买说明书、购买价格、购买日期和时间以及识别商家104的信息的一个交易批准请求发送给信用卡公司106。
商家通信模块232(图2)周期性地查问网络接口204和远程通信装置214关于输入的来自商家104的任何TAR。当接收到一个TAR，商家通信模块232就扫描卡持有者列表222以便确定是否存在一个记录502(图5)有和TAR提供的相匹配的信用卡号码504。如果在卡持有者列表222中不存在这样的记录，则商家通信模块232把一个否决的信息发送给商家104。
然而，如果被提交的信用卡号码匹配在卡持有者列表222中的一个信用卡号码502(x)，则商家通信模块232就利用在TAR中提供的信息生成字段404、406、408、410和412，而产生一个信用卡批准请求记录402，并在CARQ 220中存储新记录。起初，被确认标志414，被批准标志416和被否决标志418全被设置为0。
授权模块226的主确认模块304周期性地扫描ARQ 220，寻找待处理的TAR。基于标志414、416和418的状态处理任何待处理TAR。例如，如果第一个TAR记录402(1)的被批准的标志416(1)被全设置为0，则主确认模块304将向信用批准模块302呼叫以便执行TAR 402(1)的常规信用批准。
信用批准模块302利用本领域的技术人员所熟知的方法执行常规的信用批准处理。常规信用批准典型包括但不仅限于，用购买价格408(1)和相关的卡持有者102(x)的现存结余比较卡持有者102(x)的信贷限额512(x)的信用批准模块302。如果购买价格408(1)和相关的卡持有者102(x)的现存结余的总和小于等于信贷限额512(x)，则信用批准模块302就把被批准标志416(1)设置为1。如果在帐户中存在任何超出的差额(例如，过期未付款)，或者如果购买价格408(1)和相关的卡持有者102(x)的现存结余的总和大于信贷限额512(x)，则信用批准模块302就把被否决标志418(1)设置为1。
在CARQ 220的下一个扫描期间，主确认模块304再一次检查标志414(1)，416(1)和418(1)以便确定恰当的行为。注意，因为还没有对TAR记录402(1)进行确认处理，被确认的标志414(1)应该仍等于0。如果被否决标志418(1)设置为1，则主确认模块304就呼叫商家响应模块308以便发送一个否决信息给商家104，从CARQ 220中删除记录402(1)，并且在购买历史模块230中写入关于被否决的交易的一条记录602。如果把被批准标志416(1)设置为1，则主授权模块304检索确认被请求标志514(x)，以便确定卡持有者102(x)是否已经选择性地禁止确认处理。如果把确认被请求标志514(x)设置为0，则主确认模块304自动地把被确认标志416(1)设置为1，并在CARQ 220中留下TAR记录402(1)。如果确认被请求标志514(x)等于0，则主确认模块304把TAR记录402(1)转发给VPQ 228，以便等待卡持有者102(x)确认。
主确认模块304同时也周期性地扫描VPQ 228(例如，在每次扫描CARQ 220之后)，以便处理在VPQ 228中的任何用于确认的待处理TAR记录402。如果把具体记录402中的被确认标志414设置为1，它表示卡持有者102(x)已经确认与记录402对应的TAR。VPQ 228中记录402(1)第一次被扫描时，被确认标志414(1)和确认被启动标志415(1)均应设置为0。主确认模块304接着从卡持有者列表222中检索记录502(x)，以便确定服务器200是否应该启动确认处理(例如，把电子邮件发送给用户102(x)、寻呼用户102(x)、向用户102(x)打电话等)，或者服务器200是否应该等待用户102(x)启动确认处理。如果把启动确认标志516(x)设置为0，则主确认模块把确认被启动标志415(1)设置为1。即使服务器200没有启动确认处理，设置确认被启动标志等于1，也消除了在每次由主确认模块304扫描VPQ 228时检查确认被请求标志516(x)的需求。
在第一次扫描在VPQ 228中的记录402(1)期间，如果主确认模块304确定已经把启动确认标志516(x)设置为1，则主确认模块304就呼叫交互确认模块306，以便启动卡持有者102(x)的确认处理。交互确认模块306接着启动所述确认处理，把确认被启动标志415(x)设置等于1，并且将控制返回给主确认模块304，由后者在VPQ 228中检索用于处理的下一个记录402。
主确认模块304同时也周期性地呼叫交互确认模块306，以便对在VPQ228中待处理TAR进行实际的确认。待处理TAR的确认是通过和卡持有者102(x)建立连接来完成的，而该连接和通过最先接收TAR与商家104建立的连接是独立开的，跟现有技术的电子交易诸如ATM卡购买相比，它提供了额外的安全性。按其最广泛的可能意思，把在此使用的短语“建立连接”理解为包括但不仅限于，建立网络连接、通过调制解调器建立数据连接、通过远程通信装置建立语音连接、发送或者接收电子邮件等。从而，卡持有者102可能通过互连网络110登录服务器200、通过网络114和服务器建立直接的调制解调器的连接、通过电话向服务器200拨号、把电子邮件发送给服务器200、对来自服务器200的电子邮件答复或者任何其他的电子通信形式，来确认待处理的交易批准请求。
在一个替代实施例中，能够把系统200修改为容许帐户持有者102预先批准某些费用。例如，卡持有者列表222可能包括用于预先批准商家的字段(或者任何其他想要的标准)。然后，当处理交易批准请求时，授权模块226能够把商家识别和相关的卡持有者的被预先批准的商家名单比较，并且，如果商家出现在名单上，则自动地确认TAR。卡持有者102可能通过互连网络110、网络114或者任何其他的更新客户数据的方法访问系统200，以便修改这样的被预先批准的名单。
在如图1-3所示的本发明的具体实施例中，交互确认模块306通过卡持有者通信模块224、网络接口204以及远程通信装置214，和卡持有者102进行通信。卡持有者通信模块224为了引入连接请求(例如，电子邮件、网络连接、电话呼叫等)周期性地查问网络接口204和远程通信装置214，并且建立任何一种这样的连接。这样的通信程序(例如，电子邮件软件，网络协议等)对于本领域的技术人员来说，是众所周知的，因此为了不至于把本发明弄得主次不清，没必要作详细的描述。
交互确认模块306查问卡持有者通信模块224，以便确定是否建立有与卡持有者102的连接，并且处理每个被建立的连接。假定卡持有者102(x)已经建立了与服务器200的连接，则待处理TAR的确认会按如下过程进行。连接请求应该识别卡持有者102(x)(例如，通过信用卡号码)，并且可以有选择地包括证明代码(例如，用来证明卡持有者102(x)的个人识别号码(PIN))，以便证明卡持有者102(x)属实。交互确认模块306利用连接请求中的识别信息从卡持有者列表222中搜索对应于卡持有者102(x)的记录502(x)。接着，交互确认模块306比较在连接请求中提供的PIN和PIN 506(x)，以便证实卡持有者。如果这些PIN不匹配，则终止连接。如果这些PIN匹配，则进行确认处理。
本领域的技术人员将会认识到，在第一次收到一个不正确的PIN时，和卡持有者102(x)的连接不必终止。例如，典型地，常规的网络安全系统在断开和用户的连接之前，容许一个预定数量的不正确输入。作为选择，当稍微启动一下连接时，能够采用一些安全措施诸如停止用户试图访问系统。
接下来，交互确认模块306扫描确认待处理队列228，寻找所有信用卡号码402和卡持有者102(x)的信用卡号码504(x)匹配的TAR。接着把每个匹配的TAR提供给卡持有者102(x)确认或放弃。如果卡持有者102(x)确认具体的交易，则交互确认模块306就把该TAR记录的被确认的标志414设置为1。如果卡持有者102(x)放弃交易(例如，没有对该购买授权)，则交互确认模块306将把TAR记录被否决标志418设置为1。
根据和服务器200建立的连接类型，有多种把待处理TAR提供给卡持有者102(x)和从卡持有者102(x)接收确认指令的方法。例如，如果卡持有者102(x)和服务器200建立了HTTP连接，则可以按照因特网网页的形式提供待处理TAR。或者，如果在卡持有者102(x)和服务器200之间的连接是一个电话语音连接，则通过文本语音自动转换系统，能够把待处理TAR提供给卡持有者102(x)，诸如在现有技术中所熟知的那样。卡持有者102(x)可能接着通过语音或者键盘命令(例如，接触按钮1用来确认，触摸按钮2用来放弃)发送确认指令。仍如另一个例子所述，在连接请求是以一个电子邮件响应的形式出现的情况中，电子邮件响应可以包括由交互确认模块306可以自动处理的确认指令(例如，在电子邮件的主题栏中)。当认为利用如上所述的任何一个连接类型来确认TAR是本发明的创新点时，就不会将具体的连接类型作为本发明的一个实质性要素来考虑。
在交互确认模块306已经处理了任何一个连接请求后，把控制返回到主确认模块304，它扫描VPQ 228并转发把被确认标志414或者被否决标志41 8设置为1的任何TAR记录。此外，主确认模块304扫描在VPQ 228中存留的所有记录402，并用由系统时钟212提供的日期和时间与在购买日期和时间字段412中的值比较。如果随后的时间差值超过预定的时间间隔(例如，24小时)，则主确认模块304将把相关记录402的被否决标志418设置为1，并把记录402转发给CARQ 220。
在CARQ 220的下一个扫描期间，主确认模块304将寻找任何确认标志414和被批准标志416均被设置为1的TAR记录，呼叫商家响应模块以便把一个批准信息发送给在记录字段410中被标识的商家，从CARQ 220中删除该记录，并把一个记录602写入购买历史数据230中以便对已完成的交易存档。除了把一个否决信息而不是一个批准信息发送给被识别商家外，对否决标志418被发现设置为1的的记录进行相似处理。
图7是按照本发明总结处理TAR方法700的流程图。在第1步骤702，商家通信模块232从商家104那里接收包括完整信用卡号码的TAR，生成TAR记录402并把TAR记录402写入CARQ 220。在第2步骤704，授权模块226把TAR记录402提交给常规信用批准处理，并把被批准标志416或者被否决标志418设置为用来表示被请求的信用是被批准还是被否决。在第3步骤706，授权模块226根据被批准标志416或者被否决标志418确定是否已经批准或否决被请求信用，接着，在第4步骤708，授权模块226确定卡持有者102是否已经选择性地禁止了确认处理。如果没有选择性地禁止确认处理，则在第5步骤710，授权模块226确认与卡持有者102的交易。接着在第6步骤712，授权模块226确定卡持有者232是否已经批准TAR。如果已经确认TAR，则在第7步骤714，商家通信模块716把交易批准的信息发送给商家104。接着，在第8步骤716，授权模块226确定在CARQ220中是否还存在记录。如果在CARQ 220中不再有记录，则方法700结束。
如果在第3步骤706，授权模块226确定信用请求已经被否决，则方法700接着进行到第9步骤718，商家通信模块232把一个否决信息发送给商家104。如果在第4步骤708，授权模块226确定已经选择性地禁止了确认处理，则方法700进行到第7步骤714，在此，商家通信模块232把批准信息发送给商家104。如果在第6步骤712，授权模块226确定卡持有者102没有确认TAR，则方法700进行到第9步骤718，在此商家通信模块232把否决信息发送给商家104。最后，如果第8步骤716，授权模块226确定在CARQ 220中存在更多的待处理记录TAR，则方法700返回到第一步骤702以便处理在CARQ 220中的下一个处理。
图8是按照本发明的具体实施例总结用于实现选择性地禁止所述TAR确认处理的方法800的流程图。在第1步骤802，授权模块226确定CARQ220是否是空的。如果CARQ 220不空，则在第2步骤804，授权模块226读取在CARQ 220中的第一TAR记录。接着，在第3步骤806，授权模块226将卡持有者102和第一TAR联系起来，并从卡持有者列表222中检索与具体卡持有者对应的卡持有者记录502。在第4步骤808，授权模块226根据卡持有者记录502确定卡持有者102是否要求，在把批准信息发送给商家104之前由卡持有者102确认TAR.。如果确定已经请求(即容许)了卡持有者的确认，则在第5步骤810，授权模块226把相关的TAR记录发送给VPQ 228。接下来，在第6步骤812，授权模块226确定在CARQ 220中的最后记录是否已经被处理，如果是的话，方法800结束。
如果在第4步骤808，授权模块226确定没有要求(即禁止)确认，则在第7步骤814，自动地把被确认标志414设置为1以表示已经确认了TAR。如果在第6步骤812，授权模块226确定还没有处理在CARQ 220中的最后记录，则方法800返回到第2步骤804，开始处理在CARQ 220中的下一个记录。
图9是按照本发明总结用于确认TAR的具体方法900的流程图。在第一步骤902，授权模块226确定VPQ 228是否是空的。如果VPQ 228不空，则在第2步骤904，授权模块226读取在VPQ 228中的第一个TAR记录402。在第3步骤906，授权模块226确定是否先前就否决了TAR记录402(例如，被否决标志418＝1)。如果先前没有否决TAR，则在第4步骤908，授权模块226确定当前TAR是否先前被确认了(例如，确认标志414＝1)。如果该TAR还没有被确认，则在第5步骤910，授权模块226将确定服务器200是否已经启动了确认处理(例如，确认被启动标志415＝1)。如果确认被启动标志415等于1，则在第6步骤912，授权模块226将确定，自从服务器200接收到当前的TAR以来，预定的时间周期(例如，读取购买日期和时间412并比较系统时钟212)是否已经超过，如果超过了预定的时间周期，则在第9步骤914，授权模块226自动放弃TAR(例如，设置被标志＝1)，并且，在第8步骤916，把TAR记录转发到CARQ 220。在第9步骤918，授权模块226确定是否已经处理了在VPQ 228中的最后记录。如果在VPQ中的所有记录已经得到处理，则在第10步骤920，授权模块226执行在VPQ 228存留的任何TAR记录中的卡持有者的确认处理。
如果在第1步骤902，授权模块226确定VPQ 228是空的，则方法900结束。如果在第3步骤906，授权模块226确定已经否决了正在处理的TAR记录，则方法900直接进行到第8步骤916。类似地，如果在第4步骤908，授权模块226确定先前已经确认了TAR的处理，则方法900进行到第8步骤916。
如果在第5步骤910，授权模块226确定确认被启动标志等于0，则方法900进行到第11步骤922，在此，授权模块226还确定授权模块226是否应该启动确认处理(例如，启动确认标志516＝1)。如果在第11步骤922，授权模块226确定将要启动卡持有者的确认处理，则在第12步骤924，服务器200启动卡持有者102的确认处理，并且在第13步骤926，把已启动的确认标志设置为1。接着，方法900进行到第8步骤916。如果在第11步骤922，授权模块226确定把启动确认标志设置为0，则方法900直接进行到第13步骤926。
在第6步骤912，授权模块226确定没有超过预定时间周期间隔，则方法900进行到第8步骤916。如果，在第9步骤918，授权模块226确定在VPQ 228中存在另外的TAR记录，则方法900返回到第2步骤904，以便处理下一个TAR记录。
图10是总结用于确认卡持有者102的待处理TAR的方法1000的流程图。在第1步骤1002，卡持有者通信模块224查问网络接口204和远程通信装置214，以便确定是否存在来自卡持有者102的任何卡持有者通信请求(例如，电话呼叫、网络连接请求等)，如果存在，则在第2步骤1004，授权模块226呼叫交互确认模块306，以便建立和卡持有者102的连接。在第3步骤1006，交互确认模块306验证卡持有者102(例如，要求证明代码)，并且在第4步骤1008，搜索VPQ 228寻找与卡持有者102相关记录。接着，在第5步骤1010，交互确认模块306把待处理TAR的至少一个部分(足够卡持有者识别)提供给卡持有者102。接下来，在第6步骤1012，交互确认模块查问被建立的连接，以便确定卡持有者102是否已经发送指令来确认被提交的TAR。如果不存在来自卡持有者102确认TAR的指令，则在第7步骤1014，交互确认模块306确定卡持有者102是否已经发送了放弃TAR的指令。如果不存在放弃TAR的指令，则在第8步骤1016，交互确认模块306就确定是否已经处理了与卡持有者102相联系的最后待处理的TAR。如果已经处理了最后待处理的TAR，则在第9步骤1018，交互确认模块306将终止和卡持有者102建立连接，并且方法1000返回到步骤1002，以便确定是否存在来自其他卡持有者的任何通信请求。如果在第1步骤1002，卡持有者通信模块224确定不存在卡持有者通信请求，则方法1000结束。
如果在第6步骤1012，交互确认模块306从卡持有者102那里接收指令确认被提交的TAR，则在第10步骤就1020，交互确认模块306就把TAR记录402的被确认标志414设置为数值1，用来表示已经确认TAR。接着，方法1000返回到第5步骤1010。类似地，如果在第7步骤1014，交互确认模块306从卡持有者102那里接收到指令放弃被提交的TAR，则在第11步骤1022，交互确认模块306就把TAR记录402中的被否决标志418设置为数值1，用来表示已经放弃了该TAR。接着，方法1000返回到第5步骤1010。
在第8步骤1016，如果交互确认模块306确定没有处理具体卡持有者的最后待处理请求，则方法1000返回到第5步骤1010，以便处理具体卡持有者的下一个待处理TAR。
图11是一个替代服务器200A的方框图。除了服务器200A包括预先批准标准(PVC)1102和替代授权模块226A外，服务器200A的功能和图2的服务器200类似。授权模块226A控制和协调TAR的批准和确认，并且，除了由授权模块226执行的功能外，还使用预先确认的标准来自动地确认满足预先确认的标准1102要求的任何TAR。使用预先确认的标准1102便利了TAR的加速确认，因为授权模块226A不必等待卡持有者102的直接确认。
预先确认的标准1102是包括用于包括卡持有者102的信用卡公司106当前每个用户的个性化预先确认的标准的数据库。预先确认的标准典型地包括但不限于，商家识别标识、最大购买价格和限定在授权模块226A可以自动确认购买日期之间的日期。本领域的技术人员将会认识到预先确认的标准模块1102会是一个典型的超大文件。因此，在存储器216中显示预先确认的标准模块1102时，应认识到整个的客户文件可能被存储在一个大数据存储系统中，诸如非易失性存储器208，整个列表的某些部分当必要时会与预先确认的标准模块1102进行交换。
首先，在打开信用卡帐户时，由信用卡公司106这样确定预先确认的标准使预先确认的标准不能够确认任何购买。换言之，每个帐户的初始缺省值是这样设置的以致没有TAR满足所述预先确认的标准(例如，最大购买价格＝0)。或者，当打开所述帐户时，可以由卡持有者102确定预先确认的标准(例如，根据他们的信用卡的申请)。在这两种情况中，卡持有者102能够通过安全网络(例如，通过电话或者调制解调器访问)，修改他们的预先确认的标准，这点将在下文描述。
图12显示了授权模块226A的方框图，它包括信用批准模块302，替代主确认模块304A，交互确认模块306A和商家响应模块308。信用批准模块302通过本领域的技术人员所熟知的方法实现对在CARQ 220中存放的每个TAR的常规信用批准。主确认模块304A协调授权和确认处理，包括利用预先确认的标准进行的确认，并且负责对授权模块226A的总控制。交互确认模块306A执行与卡持有者102的确认，并协调由卡持有者对预先确认的标准的修改。商家响应模块308通过发送要么是批准信息要么是否决信息来启动和商家104的最终通信。
图13显示了适合于本发明具体实施例的、应用预先确认的标准数据结构1300的例子。本领域的技术人员将会认识到作为记录1302(1-n)的链接表的数据结构1300。每个记录1302(1-n)代表与具体卡持有者相联系的预先确认的标准，并且包括，完整的信用卡号码1304、第一商家识别标识1306(1)、第r商家识别标识1306(r)、最大预先确认的的购买价格1310、一对预先确认的日期1312、种类多样的预先确认的标准1314和指针1316。完整信用卡号码1304将具体卡持有者102(a)和预先确认的标准记录1302(a)联系起来。每个商家识别标识1306(1-r)都含有类似于每个TAR含有的商家信息410的信息。每个商家识别标识1306(1-r)都为每个卡持有者标识了预先被确认的商家。授权模块226A自动地确认从预先被确认商家那里接收的TAR。预先被确认的购买价格1310为自动确认设置了最大购买价格。授权模块226A自动地确认包括比预先确认购买价格1310低的购买价格408的任何TAR。预先确认的日期1312包括一个开始日期和一个结束日期。所有包括落在预先确认的日期1314的开始日期和结束日期之间的购买日期412的TAR由授权模块226A自动地确认。加进种类多样的预先确认的标准1314，以便说明，可能被用来使授权模块226A确认某个TAR的不是上述特定列出的具体标准。例如，当应该自动确认购买时，卡持有者102可能想要限定一天中的具体时间。对于这样一种情形，种类多样的预先确认的标准1314会包括一个起始时间和一个停止时间。指针1316(a)表示在列表中的下一个记录1316(a+1)的存储器地址。最后记录1302(n)包括表示记录1302(n)是在所述列表中的最后记录的列表值1318的结束。
图14是根据本发明的具体实施例，利用预先确认的标准总结用于实现所述自动确认TAR的方法800A的流程图。在第1步骤802，授权模块226A确定CARQ 220是否是空的。如果CARQ 220是空的，则方法800A结束。如果CARQ 220不是空的，则在第2步骤804，授权模块226A读取在CARQ220中记录的第一TAR记录。接着，在第3步骤806，授权模块226A将卡持有者102和第一TAR联系起来，并且从卡持有者列表222中检索与所述具体卡持有者对应的卡持有者记录。在第4步骤808，授权模块226A根据卡持有者记录502确定，卡持有者102是否要求在发送批准信息给商家之前要与卡持有者102确认TAR。如果确定已经请求(即容许)了卡持有者的确认，则在第5步骤809，授权模块226A确定与卡持有者102相关的预先确认的标准是否得到满足。如果在第5步骤809，预先确认的标准得不到满足，则在第6步骤810，授权模块226A把相关的TAR记录发送给VPQ 228。接下来，在第7步骤812，授权模块226A确定在CARQ 220中的最后记录是否已经被处理，并且，如果已经被处理，则方法800A结束。
如果在第4步骤808，授权模块226A确定没有要求(即禁止)确认，则方法800A进行到第8步骤814，在此，授权模块226A把被确认标志414设置为1，以表示已经确认了TAR。类似地，如果在第5步骤809，授权模块226A确定预先确认的标准得到满足，则方法800A进行到第8步骤814，在此，授权模块226A把被确认标志414设置为1。如果在第7步骤812，授权模块226A确定还没有处理在CARQ 220中的最后记录，则方法800A返回到第2步骤804，开始处理在CARQ2 20中的下一个记录。
图15是用来显示执行图14的所述方法中第5步骤809(确定所述预先确认的标准是否得到满足)的方法1500的流程图。在第1步骤1502，授权模块226A检索在所述TAR中与被标识的卡持有者(例如，卡持有者102)相联系的预先确认的标准1102的记录1302(a)。在第2步骤1504，授权模块226A确定记录1302(a)中商家识别标识1306(a)(1-r)之一是否对应在TAR中包含的商家信息410。如果记录1302(a)中的商家识别标识1306(a)(1-r)不能识别所述商家，则在第3步骤1506，授权模块226A就确定TAR的购买价格408是否低于最大预先确认的购买价格1310(a)。如果TAR中的购买价格408不低于最大预先确认的购买价格1310(a)，接着，在第4步骤1508，授权模块226A确定TAR中的购买日期412是否介于预先确认的的日期1312(a)之间。如果购买日期412不介于预先被确认日期1312(a)之间，则在第5步骤1510，授权模块226A确定种类多样的预先确认的标准1314(a)是否得到满足。如果种类多样的预先确认的标准1314(a)得不到满足，或者卡持有者没有限定任何预先确认的标准1314(a)，则方法1500确定预先确认的标准没有得到满足。
如果在第2步骤1504，授权模块226A确定记录1302(a)中的商家识别标识1306(a)(1-r)中的某个对应于TAR中包含的商家信息410，则方法1500确定预先确认的标准得到满足。如果在第3步骤1506，授权模块226A确定购买价格408低于预先被确认购买价格1310(a)，则方法1500确定预先确认的标准得到满足。类似地，如果在第4步骤1508，授权模块226A确定TAR的购买日期412介于预先被确认的日期1312(a)之间，则方法1500确定预先确认的标准得到满足。最后，如果在第5步骤1510，授权模块226A确定待处理TAR满足种类多样的预先确认的标准1314(a)，则方法1500确定预先确认的标准得到满足。本领域的技术人员将会意识到，如果各种标准中的任何一个(例如，最高购买价格)得到满足的话，方法1500将会确定具体TAR满足预先确认的标准，并因此被自动确认。
图15A是用来显示执行图14的方法中步骤809的替代方法1500A的流程图，其中，在自动确认TAR之前，所有预先确认的标准必须得到满足。在第1步骤1502，授权模块226A检索在TAR中与被标识的卡持有者(例如，卡持有者102)相联系的预先确认的标准1102的记录1302(a)。在第2步骤1504A，授权模块226A确定记录1302(a)中商家识别标识1306(1-r)之一是否对应在所述TAR中包含的商家信息410。如果记录1302(a)中商家识别标识1306(1-r)不能识别所述商家，则方法1500A确定待处理TAR不满足预先确认的标准，并且结束方法1500A。然而，如果记录1302(a)中商家识别标识1306(1-r)之一对应在TAR中的被识别商家，则方法1500A进行到第3步骤1506A，其中，授权模块226A确定TAR中的购买价格408是否低于所述最大预先被确认购买价格1310(a)，如果所述TAR的所述购买价格408不在最大预先被确认购买价格1310(a)之下，则方法1500A确定预先确认的标准得不到满足，并且结束该方法。如果TAR中的购买价格408低于最大预先被确认购买价格1310(a)，在第4步骤1508A，授权模块226A确定TAR中的购买日期412是否介于预先被确认的日期1312(a)之间。如果购买日期412不介于预先被确认的日期1312(a)之间，则方法1500A确定预先确认的标准得不到满足，并且结束该方法。如果购买日期412介于预先被确认的日期1312(a)之间，则在第5步骤1510A，授权模块226A确定种类多样的预先确认的标准1314(a)是否得到满足。如果种类多样的预先确认的标准1314(a)得不到满足，或者卡持有者没有限定任何预先确认的标准1314(a)，则方法1500A确定所述预先确认的标准没有得到满足，并且，结束方法1500A。然而，如果种类多样的预先确认的标准1314(a)得到满足，则方法1500A确定所述预先确认的标准得到满足，并且所述待处理TAR应该被自动确认。
图16是总结用于允许卡持有者102修改相关的预先确认的标准1302的方法1600的流程图。交互确认模块306A能够执行与交互确认模块306相同的功能，但是还用于协调和控制预先确认的标准1302(1-n)的修改。在第一步骤1602，卡持有者通信模块224查问网络接口204和远程通信装置214，以便确定是否存在来自卡持有者102的任何卡持有者通信请求(例如，一个电话呼叫、网络连接请求等)，如果存在，则在第2步骤1604，交互确认模块306A就和卡持有者102建立连接。在第3步骤1606，交互确认模块306A验证卡持有者102(例如，要求证明代码)，并且在第4步骤1608，交互确认模块306A搜索用于与卡持有者102相联系的预先确认的标准1302。在第5步骤1610，交互确认模块306A确定卡持有者102是否希望修改预先确认的标准1302(例如，收到响应预先记录菜单的语音响应)。如果交互确认模块306A确定卡持有者102希望修改预先确认的标准1302，则在第6步骤1612，交互确认模块306A把第一预先确认的标准(例如，商家识别标识1306(1))提供给卡持有者102。接下来，在第7步骤1614，交互确认模块306A确定卡持有者102是否希望修改在步骤1612中提供的标准，如果卡持有者102选择不修改所提供的预先确认的标准1302，则接着在第8步骤1616，交互确认模块确定卡持有者102是否想进入到下一个预先确认的标准(例如，商家识别标识1306(2))。如果所述卡持有者102不希望继续修改预先确认的标准，则交互确认模块306A在第9步骤1618，终止和卡持有者102的连接。
在第一步骤1602，如果没有来自卡持有者的通信请求，则结束方法1600。如果在步骤1610，卡持有者102不希望对预先确认的标准作任何修改，则方法1600进入第9步骤1618，其中，交互确认模块306A终止和卡持有者102的连接。如果在步骤1614，卡持有者102希望对预先确认的标准作修改，则交互确认模块306A启动第10步骤1620，其中，从卡持有者102那里接收新数据，并且在方法1600进行到第8步骤1616之前，用新数据代替所提供的预先确认的标准。如果在第8步骤1616接收到卡持有者102希望对预先确认的标准1302作更多修改的指令，则方法1600返回到步骤1610。
在此已完成本发明的具体实施例的描述。在不脱离本发明范围的情况下可以替代、变更或者忽略所描述的许多特性。例如，除了在此描述的信用卡类型帐户外，可以结合获得安全处理的替代类型帐户(例如，借方余额帐户)实现本发明。作为另一个例子，第三方确认公司108可以代表信用卡公司106采用在此描述的交易处理方法，并将确认标记信息传送给信用卡公司106。此外，当按照独立块显示图11所示的预先确认的标准1102时，本领域的技术人员将会懂得可以把预先确认的标准改为存储在其他记录里面，诸如卡持有者列表222。类似地，卡持有者通信模块224和交互确认模块306能够被合成为单个操作模块。事实上，组织和分类本发明描述的功能模块是为了清楚地说明本发明，不能机械地认为具体分离的功能的是本发明的实质要素。所示具体实施例的这些或者其他变化对于本领域的技术人员来说是容易做到的，尤其是参照前面的描述。
权利要求
1.一种用来在帐户持有者和商家之间确认商务交易的计算机系统，所述计算机系统包括一个用于处理数据和代码的处理单元；一个用于存储所述数据和所述代码的存储器装置，该代码包括一个商家通信模块，用于建立和所述商家的连接，用来接收包括一个完整帐户号码的一个交易批准请求，一个帐户持有者通信模块，用于建立和帐户持有者的一个独立连接，用于确认所述交易批准请求，和一个授权模块，对接收到所述交易批准请求作出响应，并且只要所述帐户持有者确认该批准请求的话，用来把一个批准信息发送给所述商家。
2.如权利要求1所述的一种计算机系统，其中，所述授权模块包括一个交互确认模块，对接收所述交易批准请求作出响应并且用于启动和所述帐户持有者建立的连接。
3.如权利要求2所述的一种计算机系统，还包括一个网络接口，其中，所述交互确认模块被用来通过所述网络接口把一个电子消息发送给所述帐户持有者。
4.如权利要求3所述的一种计算机系统，其中，所述交互确认模块被用来响应从所述帐户持有者那里接收答复所述电子消息，从而确认所述交易批准请求。
5.如权利要求2所述的一种计算机系统，还包括一个远程通信装置，其中，所述交互确认模块把一个自动电话呼叫发送给所述帐户持有者。
6.如权利要求5所述的一种计算机系统，其中，该交互确认模块被用来建立和所述帐户持有者的电话连接；至少把所述交易批准请求的一部分复述给该帐户持有者；并从该帐户持有者处接收关于该交易批准请求的确认指令。
7.如权利要求6所述的一种计算机系统，其中，该交互确认模块还被用来，在至少把该交易批准请求的一部分复述给该帐户持有者的所述步骤之前，从该帐户持有者那里索取一个认证代码。
8.如权利要求1所述的一种计算机系统，其中，所述授权模块包括一个交互确认模块，用来等待所述帐户持有者启动与其的所述连接。
9.如权利要求8所述的一种计算机系统，还包括一个网络接口，其中，该交互确认模块用来通过所述网络接口等待来自所述帐户持有者的通信。
10.如权利要求8所述的一种计算机系统，还包括一个网络接口，其中，所述交互确认模块用来通过该网络接口从所述帐户持有者那里接收一个连接请求；建立和该帐户持有者的网络通信；验证该帐户持有者；通过该网络接口至少把所述批准请求的一部分发送给该帐户持有者；并且从该帐户持有者那里接收关于该批准请求的确认指令。
11.如权利要求8所述的一种计算机系统，还包括一个远程通信装置，并且其中，所述交互确认模块用来等待来自所述帐户持有者的电话呼叫。
12.如权利要求8所述的一种计算机系统，还包括一个远程通信装置，其中，所述交互确认模块被用来从所述帐户持有者那里接收一个电话呼叫；验证该帐户持有者；至少把所述交易批准请求的一部分复述给该帐户持有者；并且，从该帐户持有者处接收关于该交易批准请求的确认指令。
13.如权利要求1所述的一种计算机系统，其中，响应来自所述帐户持有者的指令的所述授权模块，在没有进一步从该帐户持有者输入的情况下，被用来自动地确认后继的交易批准请求。
14.如权利要求1所述的一种计算机系统，其中，所述授权模块包括一个主确认模块，用来响应某个预定时间周期的流逝，并且如果所述帐户持有者还没有确认所述批准请求的话，用来放弃该批准请求。
15.如权利要求14所述的一种计算机系统，其中，所述主确认模块还用于，当放弃所述交易批准请求时把通知发送给所述帐户持有者。
16.如权利要求1所述的一种计算机系统，其中所述交易批准请求是来自第三方金融机构的一个确认请求；并且，所述授权模块用来把确认标记发送给所述第三方金融机构。
17.在计算机系统中用于确认在帐户持有者和商家之间商务交易的一种方法，所述方法包括接收来自所述商家的一个交易批准请求，所述批准请求包括一个确认所述帐户持有者帐户的完整的帐户号码；通过和所述商家的通信分离开的、和所述帐户持有者的通信，电子地与该帐户持有者确认该交易批准请求；并且，只要所述帐户持有者确认了所述交易批准请求，则把一个批准信息发送给所述商家。
18.如权利要求17所述的一种方法，其中，确认关于所述卡持有者的交易批准请求的步骤包括，提醒所述帐户持有者确认该交易批准请求。
19.如权利要求18所述的一种方法，其中所述提醒该帐户持有者确认所述交易批准请求的步骤包括，把一个电子消息发送给该帐户持有者。
20.如权利要求19所述的一种方法，其中关于该帐户持有者的该交易批准请求的所述步骤包括，接收一个对所述电子消息的答复。
21.如权利要求18所述的一种方法，其中提醒所述帐户持有者确认所述交易批准请求的步骤包括，向该帐户持有者发送一个自动电话呼叫。
22.如权利要求21所述的一种方法，其中向所述帐户持有者发送一个自动电话呼叫的步骤包括建立和该帐户持有者的一个电话连接；至少把该交易批准请求的一部分复述给该帐户持有者；并从该帐户持有者处接收关于该交易批准请求的确认指令。
23.如权利要求22所述的一种方法，其中向所述帐户持有者发送一个自动电话呼叫的步骤还包括，在所述把该交易批准请求的至少一部分复述给该帐户持有者的步骤之前，接收来自该帐户持有者的一个验证代码。
24.如权利要求17所述的一种方法，其中，所述电子地与该帐户持有者确认该交易批准请求的步骤，包括等待该帐户持有者启动和所述计算机系统的通信。
25.如权利要求24所述的一种方法，其中，由该帐户持有者通过一个网络连接启动与所述计算机系统的通信。
26.如权利要求24所述的一种方法，其中，所述电子地与该帐户持有者确认该交易批准请求的步骤包括通过一个网络接口从该帐户持有者处接收一个连接请求；建立和该帐户持有者的一个网络通信；验证该帐户持有者；至少把所述交易批准请求的一部分发送给该帐户持有者；并且从该帐户持有者那里接收关于该交易批准请求的确认指令。
27.如权利要求24所述的一种方法，其中由所述帐户持有者通过电话连接启动和所述计算机系统的通信。
28.如权利要求24所述的一种方法，其中，所述电子地与该帐户持有者确认该交易批准请求的步骤包括从该帐户持有者处接收一个电话呼叫；验证该帐户持有者；至少把所述交易批准请求的一部分复述给所述帐户持有者；并且，从该帐户持有者接收关于该交易批准请求的确认指令。
29.如权利要求17所述的一种方法，其中，所述帐户持有者能够选择性地容许或者禁止，所述电子地与该帐户持有者确认该交易批准请求的步骤。
30.如权利要求17所述的一种方法，其中，所述电子地与该帐户持有者确认该交易批准请求的步骤包括，如果在预定时间间隔内该帐户持有者没有确认该交易批准请求，则自动放弃该批准请求。
31.如权利要求30所述的一种方法，还包括，当放弃该交易批准请求时，把通知发送给该帐户持有者。
32.如权利要求17所述的一种方法，其中从所述商家那里接收所述交易批准请求的步骤包括，从接收该商家交易批准请求的第三方金融机构那里接收一个确认请求；和把一个批准信息发送给该商家的步骤包括把确认标志发送给所述第三方金融机构。
33.一种其中包含用于使电子装置执行如权利要求17所述方法的代码的计算机可读介质。
34.一种其中包含用于使电子装置执行如权利要求18所述方法的代码的计算机可读介质。
35.一种其中包含用于使电子装置执行如权利要求19所述方法的代码的计算机可读介质。
36.一种其中包含用于使电子装置执行如权利要求20所述方法的代码的计算机可读介质。
37.一种其中包含用于使电子装置执行如权利要求21所述方法的代码的计算机可读介质。
38.一种其中包含用于使电子装置执行如权利要求22所述方法的代码的计算机可读介质。
39.一种其中包含用于使电子装置执行如权利要求23所述方法的代码的计算机可读介质。
40.一种其中包含用于使电子装置执行如权利要求24所述方法的代码的计算机可读介质。
41.一种其中包含用于使电子装置执行如权利要求25所述方法的代码的计算机可读介质。
42.一种其中包含用于使电子装置执行如权利要求26所述方法的代码的计算机可读介质。
43.一种其中包含用于使电子装置执行如权利要求27所述方法的代码的计算机可读介质。
44.一种其中包含用于使电子装置执行如权利要求28所述方法的代码的计算机可读介质。
45.一种其中包含用于使电子装置执行如权利要求29所述方法的代码的计算机可读介质。
46.一种其中包含用于使电子装置执行如权利要求30所述方法的代码的计算机可读介质。
47.一种其中包含用于使电子装置执行如权利要求31所述方法的代码的计算机可读介质。
48.一种其中包含用于使电子装置执行如权利要求32所述方法的代码的计算机可读介质。
49.一种用来确认在卡持有者和商家之间的商务交易的计算机系统，所述计算机系统包括一个用来处理数据和代码的处理单元；和一个用来存储所述数据和所述代码的存储器装置，所述代码包括一个商家通信模块，用于建立和所述商家的连接，用来接收包括与所述帐户持有者相联系的完整帐户号码的一个交易批准请求，所述数据包括与该帐户持有者相联系的至少一个预先确认的标准，所述代码还包括一个响应所述交易批准请求的授权模块，用来比较该交易批准请求和所述预先确认的标准，如果至少一个预先确认的标准得到满足，则确认该交易批准请求。
50.如权利要求49所述的一种计算机系统，其中所述至少一条预先确认的标准包括多项预先确认的标准；并且，所述授权模块在至少一项预先确认的标准得到满足时，确认所述交易批准请求。
51.如权利要求49所述的一种计算机系统，其中所述至少一条预先确认的标准包括多项预先确认的标准；并且，所述授权模块只有在所述多项预先确认的标准全部得到满足时，才确认所述交易批准请求。
52.如权利要求49所述的一种计算机系统，其中，由所述帐户持有者确定所述预先确认的标准。
53.如权利要求49所述的一种计算机系统，还包括一个帐户持有者通信模块，用于接收来自所述帐户持有者的连接请求；建立与该帐户持有者的连接；验证该帐户持有者；把所述预先确认的标准的至少一个提供给该帐户持有者；并且，从该帐户持有者那里接收用于修改该预先确认的标准之一的指令。
54.如权利要求53所述的一种计算机系统，其中，在接收到来自所述帐户持有者的所述修改指令之前，所述交易批准请求没有一个能够满足所述预先确认的标准。
55.如权利要求49所述的一种计算机系统，其中，所述预先确认的标准包括至少一个商家识别标识。
56.如权利要求55所述的一种计算机系统，其中，所述授权模块，对接收到所述交易批准请求作出响应，用来把所述商家发送的所述交易批准请求和每个商家识别标识进行比较；如果通过某个商家识别标识识别出该商家发送的所述交易批准请求，则确认该交易批准请求。
57.如权利要求49所述的一种计算机系统，其中，所述预先确认的标准包括一个最大预先确认的购买价格。
58.如权利要求57所述的一种计算机系统，其中，所述授权模块，对接收到所述交易批准请求作出响应，用来把在该交易批准请求里包含的购买价格和所述最大预先确认的购买价格进行比较；并且，如果在该交易批准请求里包含的购买价格小于该最大预先确认的购买价格，则确认该交易批准请求。
59.如权利要求49所述的一种计算机系统，其中，所述预先确认的标准包括一个起始日期和一个结束日期。
60.如权利要求59所述的一种计算机系统，其中所述授权模块，对接收到所述交易批准请求作出响应，用来把该交易批准请求包含的购买日期和所述起始日期和所述结束日期进行比较；并且，如果该购买日期介于该起始日期和该结束日期之间，则确认该批准请求。
61.在某个计算机系统中，用于确认在帐户持有者和商家之间的商务交易的一种方法，所述方法包括存储与所述帐户持有者相联系的至少一个预先确认的标准；接收来自所述商家的交易批准请求，所述交易批准请求包括与该帐户持有者相联系的一个完整的帐户号码；把该交易批准请求和该预先确认的标准进行比较；并且，如果该预先确认的标准得到满足，确认所述交易批准请求。
62.如权利要求61所述的一种方法，其中用来存储至少一条预先确认的标准的步骤包括存储多项预先确认的标准；并且，确认所述交易批准请求的步骤包括，如果至少一个所述预先确认的标准得到满足，则确认该交易批准请求。
63.如权利要求61所述的一种方法，其中用来存储至少一条预先确认的标准的步骤包括存储多项预先确认的标准；并且，确认所述交易批准请求的所述步骤包括，只有所述预先确认的标准全部得到满足，才确认该交易批准请求。
64.如权利要求61所述的一种方法，其中，由所述帐户持有者确定所述至少一个预先确认的标准。
65.如权利要求61所述的一种方法，还包括建立和所述帐户持有者的一个连接；验证该帐户持有者；并且，允许该帐户持有者修改与该帐户持有者相联系的所述预先确认的标准。
66.如权利要求65所述的一种方法，其中，在所述帐户持有者修改之前，所述预先确认的标准不能得到满足。
67.如权利要求61所述的一种方法，其中，所述预先确认的标准包括至少一个商家识别标识。
68.如权利要求67所述的一种方法，其中所述预先确认的标准包括多个商家识别标识；如果所述多个商家识别标识中的某一个标识出所述商家，则确认所述交易批准请求。
69.如权利要求61所述的一种方法，其中，所述预先确认的标准包括一个预先确认的购买价格。
70.如权利要求69所述的一种方法，其中，如果在所述交易批准请求中识别的某个购买价格小于所述预先确认的的购买价格，则确认该交易批准请求。
71.如权利要求61所述的一种方法，其中，所述预先确认的标准包括至少一个预先确认的日期。
72.如权利要求71所述的一种方法，其中所述预先确认的标准包括至少一对预先确认的日期；而且如果在所述交易批准请求中包含的交易日期介于所述预先确认的日期之间，则确认该交易批准请求。
73.一种其中包含用于使电子装置执行如权利要求61所述方法的代码的计算机可读介质。
74.一种其中包含用于使电子装置执行如权利要求62所述方法的代码的计算机可读介质。
75.一种其中包含用于使电子装置执行如权利要求63所述方法的代码的计算机可读介质。
76.一种其中包含用于使电子装置执行如权利要求64所述方法的代码的计算机可读介质。
77.一种其中包含用于使电子装置执行如权利要求65所述方法的代码的计算机可读介质。
78.一种其中包含用于使电子装置执行如权利要求66所述方法的代码的计算机可读介质。
79.一种其中包含用于使电子装置执行如权利要求67所述方法的代码的计算机可读介质。
80一种其中包含用于使电子装置执行如权利要求68所述方法的代码的计算机可读介质。
81.一种其中包含用于使电子装置执行如权利要求69所述方法的代码的计算机可读介质。
82.一种其中包含用于使电子装置执行如权利要求70所述方法的代码的计算机可读介质。
83.一种其中包含用于使电子装置执行如权利要求71所述方法的代码的计算机可读介质。
84.一种其中包含用于使电子装置执行如权利要求72所述方法的代码的计算机可读介质。
全文摘要
本发明公开了用于在卡持有者、商家和信用卡公司之间确认商务交易的一种系统和方法。卡持有者利用完整的信用卡号码和商家做一次购买交易。该商家提交一份交易批准请求，让信用卡公司批准(702)。该信用卡公司对所述交易批准请求执行常规的信用核准(704，706)，同时也与卡持有者确认该交易批准请求(710)。只有在对信用卡公司进行了常规的核准和卡持有者进行了确认之后，才把批准信息发送给所述商家(714)。该卡持有者或者信用卡公司能够提出对该交易批准请求进行确认。如果在所述交易批准请求中包含的数据满足一个或者多个预先确认的标准，则也能够自动地被确认。卡持有者能够初始确定和/或修改所述预先确认的标准。
文档编号G06Q20/00GK1449537SQ01812985
公开日2003年10月15日 申请日期2001年7月16日 优先权日2000年7月17日
发明者戴维·N·哈里斯 申请人:戴维·N·哈里斯