本发明总体上涉及用户认证，该用户认证作为与期望对其进行一些形式的访问的实体进行电子交易的前序。更具体地，本发明涉及用于通过使用如本文所公开的那样生成并管理的安全码来确保电子交易或其他安全电子访问的安全的系统和方法。
背景技术：
其中可靠的用户认证非常重要的一个示例是在电子支付交易的领域。
在线信用卡、借记卡和预付卡的诈骗正随着在线购物和第三方账单支付的大量使用而增加。虽然新技术通过使用emv(europay、mastercard和visa——也就是“带芯片”卡)以及卡终端加密解决了商户销售点(pos)终端处的“有卡(cardpresent)”诈骗，但是当前针对在线“无卡(cardnotpresent)”(cnp)诈骗问题的安全措施仍显不足。
在美国，cnp诈骗数量庞大而且仍在增加。2013年仅针对信用卡交易的估计诈骗损失就达到28亿美元，在接下来的10年间，在线诈骗的信用卡购买预计将以两位数增长，截止2018年达到估计64亿美元。
借记卡和预付卡诈骗使得经济损失数字更加恶化。由于诈骗增加，随之而来的是针对诈骗赔偿、管理和运营的更高金融机构(fi)成本。金融机构还面临着持卡人信心受挫以及潜在的客户损失。因此具有重大的市场影响。
此外，自动票据交换所(ach)的扣款支付正随着虚拟支票(无支票)支付的增多有所增加。ach扣款是廉价的，但同时对于账户持有人方的控制十分有限。在消费者与销售方建立支付时，销售方/商户/收款方经常被给予访问个人支票账户的宽松(且经常是无限制的)许可。
在支付卡的领域(包括在cnp交易中的使用)，已知将简短(通常为3或4位)数字码与支付卡进行关联来提高给定支付交易正在利用手中的真实卡片，或者通过(为商户或其他收款人)建立持卡人在cnp交易期间将卡片拿在手中(例如，通过电话)的指示进行的可信度。
现有若干种这些常规安全码。
第一种常规安全码一般被称作cvv1(卡验证值)。该代码在本领域有时也被称作cvc1(卡验证码)。该代码以可见方式编码在卡片的磁条上并且在例如在有卡交易期间在属于商户的pos终端刷卡时被获取。其作为交易的一部分被传递，并且由发卡方进行验证。cvv1码的验证确认支付卡实际上正被刷这张卡的商户(或其他实体)物理处置。
被记录在卡片磁条上的cvv1码是静态的，并且对于给定支付卡是特定的。如果卡片被物理复制并且磁条数据被拷贝，则cvv1码将仍然有效并且甚至能够由非授权用户所使用。
第二种常规安全码一般被称作cvv2(或者有时被称作cvc2)。cvv2码是与卡的账号号码分开印在支付卡上的固定数字(例如，在背面的签名条上，或者偶尔在前面与账户号码分离)。cvv2码被用于cnp交易(诸如商品或服务的电话或在线购买)并且意在表明发起该交易的人拥有该卡片或者已经看到了该卡片的物理记录(其上具有cvv2码)。除其他形式的错误使用之外，cvv2码的使用有助于防止词条信息被欺诈性拷贝(在技术上讲是相对简单的步骤)并且随后被用于cnp交易的情形。大多数cnp交易将要求额外了解cvv2码。依据行业公约，cvv2码在电子支付交易期间并不被商户和收款方所存储。因此，如果交易信息(例如，包括消费者支付卡账户号码)被盗用或以其他方式从商户或收款方处窃取，该信息在不了解相对应的cvv2码的情况下也不太有用。
像cvv1码一样，cvv2码是静态的(即，针对给定的物理支付卡是无法改变的)，并且与该单一支付卡唯一关联。即使(按照公约或者按照商户和支付处理方之间的明确协定)cvv2码理论上并不被保留，但是仍无法避免暗中拷贝或保留该代码的不良人员。应当注意的是，如常规所采用的，cvv2码在支付卡的一面上是清晰可见的，从而在卡片被盗的情况下能够被盗用。
个人识别号码(pin)的使用也是普遍所知的，例如，与信用卡的使用相关联地使用。在常规示例中，刷支付卡来读取卡片磁条中的账户信息，并且由用户在键盘或其他输入设备上手工输入pin。与银行或金融机构建立通信链路，允许卡片信息和所输入的pin的传输。
常规地，给定pin码通常与单个相应支付卡或者用户想要进行访问的其他电子实体或系统相关联。这加剧了用户必须管理、记住并确保安全(即，保护其免于丢失和/或非授权访问)的单独安全码的扩散。
fi、商户和消费者全部都期望一种解决方案，该解决方案通过使得诈骗最少化、减少数据外泄、减少品牌声誉风险，同时加强对何时进行交易、它们何时及如何被授权以及货币何时转移的控制来降低交易风险。
因此，期望找到一种解决现有技术的一些问题的安全解决方案：使得fi和商户免于非授权交易或诈骗损失的货币损失；为账户持有人提供对交易更大的控制；使得授权处理和交易完成中的冲突最小化；改善更强大的安全过程的采用。
fi将不会牺牲承受着支付卡或支票交易的非居间化(disintermediation)风险(也就是失去与可能已经构建了更加安全或不同的交易方式的第三方介入者的交易的风险)的市场份额，账户持有人和在线购买交易额。商户想要使得放弃购买、退款和争议交易最少化。一种优选解决方案将使得对现有处理的利用最大化，是易于整合的、可缩放的，而且将不会损及认证处理的速度。
一种具有吸引力的解决方案将解决在线购买交易的所有各方——fi、持卡人和账户持有人以及商户——的需求。优选地，这样的解决方案将减少cnp诈骗，限制fi隐患，减少诈骗、争议和退款成本，并且为持卡人和账户持有人提供附加好处。
技术实现要素：
最为一般地，本发明涉及用于访问用户想要访问的安全实体并与之进行交互时的用户认证的系统和方法，所述安全实体尤其是电子实体，诸如安全计算机网络或者私有或商业网站。然而，本发明能够明确被应用于用于由个人对安全建筑物等进行物理访问的系统。本发明的特定方面涉及到用于用户认证的安全码的生成、传播和管理。
在本发明的特定非限制示例中，本发明涉及用于提高电子交易——尤其是电子支付交易——中的用户认证处理的安全性，同时用户在使用和管理所要求的安全码时还使得采用负担最小化且使得便利性最大化的系统和方法。
本发明依赖于用于用户认证的单个有限使用期的随机化安全码，所述安全码能够跨属于该用户的一系列支付模式(诸如信用卡、借记卡、支票账户等)来使用，而不是拥有分别绑定至相应支付模式的多个安全码。这方便地减少了用户必须记住并保护的安全码的数量。
然而，与此同时，所述安全码具有有限使用期(例如，一天)并且相应地发生变化，这减少了代码在任何给定时刻丢失的情况下的安全隐患。而且，所述代码能够在检测到欺诈性使用等的迹象的情况下被轻易改变，或者(多个之中的)特定账户或支付模式能够响应于卡片丢失或检测到受限欺诈性使用(即，针对某些账户或支付模式)而在可能需要的情况下有选择地(或自动地)被锁定和解锁。
在本发明的示例中，生成虚拟矩阵，其中多个相应用户(例如，支付账户持有人)与随机生成的安全码的相应集合相关联。每个安全码具有某个有效时段，其并不与关联于给定用户的集合中的其他安全码的有效性相重合(或者如以下所解释的具有最小重合)。所述矩阵的当前(关于用户和/或安全码的当前集合)版本被定期分发至支付处理方或金融机构，而使得其能够被参照用于认证。与之并行地，至少给定用户的当前有效安全码被传递至该用户。
在本发明的特定示例中，有关所述矩阵(特别是安全码)的信息在所述矩阵被分发至相应支付处理方之前以数学方式进行模糊(例如，使用散列函数)。优选地，模糊方法对于每个支付处理方是唯一的，诸如通过针对每个支付处理方使用唯一的相应散列盐值(hashsalt)。
在实践中，处理电子支付交易的请求连同用于对发起所述电子支付交易请求的声称授权用户的认证的安全码之一一起被相关支付处理方所接收。针对对应于处理电子支付交易的请求的时间的有效期，由所述支付处理方将所接收的安全码与对应于所述声称授权用户的当前矩阵中的安全码进行比较。所述交易根据比较而被批准或拒绝。
附图说明
结合该文字描述，本发明将参考随文所附的附图而得到更加清楚的理解，其中：
图1是图示电子支付交易中的各个“玩家”之间的互连以及与之相关联的硬件部署的高阶示意性图示；
图2图示了生成根据本发明的安全码的群组的过程，包括各个支付处理实体之间与之相关的交互；
图2a图示了如何生成临时获知的随机模式矩阵的示例；
图3图示了为了使用本发明所进行的初始用户注册的过程；
图3a-3h图示了各种注册过程，包括对各个账户进行分组或者要求安全码从而具有全体安全性的其他实施方式；
图4图示了将根据本发明的安全码传递至用户的过程；
图5图示了使用本发明的安全码而使用信用卡或借记卡或者支票进行电子支付的步骤；
图6图示了对电子支付交易授权的进一步的步骤；
图7图示了在图6的架构内验证所提交的安全码的进一步的步骤；
图8图示了在图6的架构内记录和分析交易结果的步骤；
图9图示了向用户发送通知的过程，该过程作为本发明的若干其他过程的一部分来使用；
图10图示了与本发明相关联的有选择地锁定或解锁金融账户的过程；
图11图示了向支付处理方或金融机构发送通知的过程；和
图12图示了验证电子支付交易的过程。
具体实施方式
所要理解的是，本文所公开的本发明各个方面的细节专门意在能够在最大可能范围内以各种组合被应用于本发明的宽泛概念，即使本文并未就此意义进行具体的语言描述。
出于本公开的目的，总体上预期以下定义，因为本文可能进一步有所修改。
“账户”是存储资金并且能够出于购买和销售商品和服务的目的而转移资金的任意金融关系。通常，账户可以包括但并不局限于：支票、储蓄、信贷额度、信用卡、借记卡、预付卡(包括工资单、礼品&奖励)、数字钱包、私人标记ach卡、解除绑定的借记卡，具有或没有用于进行购买、电子资金转移(eft)或者以其他方式进行的资金转移的虚拟或物理卡或支票。
“交易”是无论是在企业、家庭、个人、政府还是其他公共或私人组织之间通过计算机为媒介的网络所进行的货币转移，其能够以在线或离线方式来进行。
“支付处理方”是指接收电子支付请求并且充当校验所述电子支付请求的细节并处理资金从相关金融机构(诸如发卡银行)到商户或收款方的转移的中介的实体。如所指示的，支付处理方例如可以是卡支付处理方或收款保管金融机构或银行。就它们在支付处理方活动中被涉及的范围而言，其还意在涵盖自动票据交换所(ach)和联邦储备。然而，出于简化本文公开内容的原因，原则上将在上下文中使用术语“支付处理方”而并非意在上述解释的背景下进行限定。
图1示意性地图示了本发明被整合于其中的用于执行电子支付交易的系统。
图1所示的主要部件可以直接或可操作地相互通信。与另一个部件处于“可操作通信”意在包含两个部件之间的通信路径中存在中间部件的可能性，即使这样的中间部件并非必然被明确指示。所图示的部件的“分组”(诸如在“中央系统”中)就它们并非意在要求任何程度的物理接近度(在常规网络原则的限制内)的意义而言是示意性的，虽然接近显然是可允许的。而且，图1中的部件之间的通信“链路”意在反映出这些部件的整体相互关系，而并非意在限制或者尤其并非意在是排他(即，图1中并未图示的其他通信链路可能存在于所图示的部件之间)。
如图1所示的“中央系统”包括执行根据本发明的操作的主要部分的部件。作为示例而非限制，中央数据库服务器1是被托管于专用或虚拟硬件系统中，位于云端或本地数据中心中的数据库集，其集中保存用于本发明的支持数据，包括：账户持有人登记资料以及他们的相对应信息和偏好，诸如通知偏好或条件交易规则或账户锁定偏好；所生成的安全码(在本文有时被称作临时获知的随机模式)，其如下文所解释的那样被生成以便将它们向外分发给参与的支付处理方，以及向所登记的账户持有人通知他们当前针对在账户持有人的资料中注册的所有账户有效的当前安全码；以及有关尝试在所注册账户上进行的交易的信息。中央数据库服务器1的示例是amazonrelationaldatabaseservice(有时称作amazonrds)，其允许在远程系统上创建和操作虚拟服务器。物理服务器的实施方式根据本发明也将是有效的。
硬件安全模块(hsm)2可以位于云端或本地，并且被用来安全地生成、存储和管理加密密钥，所述加密密钥被用来对根据本发明的操作过程中所生成并处理的敏感信息进行加密或散列。如以下所解释的，其还可以被用于真随机数生成以填充安全码矩阵(即，将用户与相应安全码集合相关联的矩阵，其中每个个体安全码具有各自的有效期)。可商业获得的hsm2的实施方式例如能够从amazonwebservices获得，并且例如基于来自safenet公司的使用lunasa软件(第5版)的lunasa700hsm应用。如本领域已知的，“真”随机数生成依赖于在科学上随基带物理现象(诸如无线电接收器所检测到的大气噪声或者放射性衰变)而使得所生成数字的随机性最大化，并且因此是用于在本发明中使用的优选方法。
中央应用服务器3是位于云端或本地的中层应用服务器或服务器集合，其专用于有效执行实施系统的商业逻辑的功能和过程。(“中层”通常是指执行应用的商业逻辑并且在操作上位于用户界面或web服务器与作为多层结构的一部分的(多个)数据库服务器之间的应用服务器。)它保存执行这些软件模块所必须的架构，并且连接至中央数据库服务器1以支持必要的以数据为中心的操作。它还托管针对外部客户端或供应商的api(应用程序接口)调用以与中央数据库服务器1进行通信以便管理账户持有人登记、账户持有人偏好，或者从处理方(或者发行方或金融机构)接收交易信息。出于这些过程描述的目的，它还负责向外连接至其他供应商以传送文件或数据有效载荷从而实现不同应用特征，诸如b2b(企业对企业)通信或者通过通知服务器9(例如，电子邮件交换服务器、sms整合器、移动应用推送警告服务，或者将这些服务中的全部或一些整合在一起的web服务提供方，例如作为amazonwebservices解决方案的一部分的amazonsimplenotificationsservice)进行的账户持有人通知。这些功能中的一些也可以在用于更深、更加分布的多层架构中的单独硬件系统中实施。能够商业获得的中央应用服务器3的示例是amazonelasticcomputecloud(有时被称作amazonec2)，但是物理服务器实施方式根据本发明也是适宜的。
在图1所指示的示例“支付处理方”(或者以类似方式部署的电子支付处理所涉及的金融机构)，提供了一个或多个数据库服务器4、6，它们进而处置和处理多个各种数据库。通常，支付处理方将已经拥有一个或多个数据库服务器(以及在其上运行的数据库)以便执行常规操作。根据本发明的支付处理方处的某些操作也是驻留于数据库服务器的，并且能够在现有硬件上实施或者在期望的情况下能够在独立数据库服务器(或多个服务器)上实施。利用适当的连接，所要求的实施方式并不需要处于支付处理方本地，而是例如能够位于中央系统本地或者处于另一个物理位置。以此为背景，出于本公开的简明和清楚的原因，本发明的本公开以与支付处理方相关联的两个服务器为例进行了描述，所述两个服务器是物理上独立的单元。然而，以上所有的考虑适用于本发明，并且如本文所描述的归于一个数据库服务器的功能能够在其他数据库服务器中实施。
因此，可以提供具有根据本发明的安全码数据库服务器4的支付处理方，其与中央系统(即，包括中央数据库服务器1、hsm2和应用服务器3)进行通信。安全码数据库服务器4的可商业获得的示例是dell13gpoweredger730xd。安全码数据库服务器4表示包含允许参与的支付处理方根据本发明完成交易的必要数据和过程的数据库集的实例，包括验证根据本发明而生成以及由所登记账户持有人在执行电子支付交易时输入的安全码。这些实例可以以实施为单独硬件系统，专用或虚拟，在云端或本地，或者在支付处理方的现有数据库服务器上的现有数据库实例内(即，被整合到支付处理方的已有设备中)。支付处理方通常还将具有一个或多个其自己的已有数据库服务器6。数据库服务器6通常是参与的支付处理方或金融机构所拥有和/或操作的数据库集，被托管在专用或虚拟硬件系统中，被保存在云端或本地数据中心，其包含总体上(即，根据或并不根据本发明)处理交易认证所必要的数据和方法。
在图5图示了代表性的账户持有人(或者换言之，具有一个或多个金融账户并且寻求经由电子支付交易为商品或服务等进行支付的消费者)。通常，账户可以包括但并不局限于：支票、储蓄、信贷额度、信用卡、借记卡、预付卡(包括工资单、礼品&奖励)、数字钱包、私人标记ach卡、解除绑定的借记卡(即，由一个实体所发行但是链接至与另一个实体相关联的账户(通常是资金来源)的账户)，具有或没有用于进行购买、电子资金转移(eft)或者以其他方式进行的资金转移的虚拟或物理卡或支票。特别地，关于支付卡，本发明意在应用于开环、闭环、单次储值和可重复储值的卡。如本领域已知的，“开环”支付卡是指在商户间具有一般承兑的卡片类型(诸如
账户持有人5可以不时地完成金融交易，特别是电子支付交易。“交易”是通过以计算机为媒介的网络在是在企业、家庭、个人、政府以及其他公共或私人组织之间进行的货币转移，所述转移可以在线或离线进行。
账户持有人5可以从个人电子设备发起所期望的金融交易，所述电子设备诸如台式或膝上计算机、平板计算机、智能电话、蜂窝电话，或者任意其他便携或附属设备，但是并不局限于此。可替换地，交易能够经由“现场”消费者服务代理(通过电话或面对面地)来进行。
用于与本发明的系统进行对接的适当接口可以包括网站、移动或台式机应用或小程序或者文本消息，它们与托管于中央应用服务器3的应用编程接口(api)进行连接并且向其发出直接或间接调用，以便(作为示例)根据本发明来管理登记资料和偏好，包括通知偏好或者有条件交易或账户锁定偏好；根据本发明接收有关交易、登记资料变化的警告和通知，或者根据本发明得到当前安全码；发起管理账户状态或系统行为的请求，诸如永久或临时，完全或有条件地锁定账户而不参与交易，或者向发行银行告知国际旅行或者支付卡或设备已经被盗用、损坏、丢失或被窃。
账户持有人可以不时地与商户(或收款方)7或中间计费实体(未示出)进行交互以进行购买或其他支付交易并且提交交易认证请求。交易认证可能包括：在网站、移动或台式应用上进行的消费者不在场的交易认证请求(例如无卡交易)，或者通过语音通信(例如通过电话与现场代理或自动语音识别系统)，或者经过通过使用诸如指纹或语音识别或视网膜扫描的生物计量特征扫描将交易信息传输至商户或收款方7的设备；或者消费者在场交易(例如，有卡交易)，其中账户持有人5亲自向商户(或收款方7)出示利用其进行购买或支付的金融账户的支付卡、支票、设备、芯片，或者任意表示形式。
出于本发明的目的，商户(或收款方7)是例如通过被用来完成账户持有人5所发起的卡交易认证的设备或装置而接受诸如借记、信贷、支票或ach之类的支付方法的任意实体。这可以由安装在账户持有人有权访问或以其他方式进行操作的设备上的web应用或移动应用所表示。它还可以是处于商户位置的物理设备(如销售点终端)，账户持有人可以利用其而通过键入或扫描卡片或者其物理或虚拟表示形式上所包含的信息，或者通过扫描账户持有人的生物计量特征来输入交易信息，以上仅是举出几个示例。在本发明的某些示例中，商户7例如可以操作hpmoonshotproliantm350。
根据本发明可能需要一个或多个附加的web服务器8，例如用于托管网站或web应用以便与账户持有人5进行对接。这里也可以使用以上所提到的amazonec2的示例。web服务器8可以位于中央系统内、云端，或者处于本地数据中心。web服务器8也可以是支付处理方的局域网的一部分。该功能也可以由托管用于从账户持有人5接收输入来管理登记以及为账户持有人5呈现登记和其他相关信息的应用、网站或api的第三方实体所提供，所述其他相关信息诸如根据本发明的当前安全码。
最后，通知服务器9(作为示例而非限制，hpmoonshotproliantm800)可以是充当向账户持有人5传递或推送通知的中介的任意服务器。这样的服务器或服务器群组的一些示例可以是用于处理和传递电子邮件消息的交换服务器，或者处理以及向属于账户持有人5的蜂窝电话传递sms文本消息的sms汇总方服务器，或者将这些服务器中的全部或一些汇总在一起的web服务提供方(例如，amazonwebservices解决方案内的amazonsimplenotificationsservice)。
下文是图1中所表示的服务器交互/连接的概述。许多内容将关于根据本发明的各种过程的具体解释来详细讨论。
<a>：中央数据库服务器1例如通过sqlclrassembly向hsm2api发出调用，以便从基于硬件的真随机数生成器(rng)获取真随机数，或者安全存储并获取加密密钥以对敏感信息进行散列或加密，所述敏感信息诸如根据本发明而生成的安全码。
<b>：中央应用服务器3连接至中央数据库1以便提交账户持有人的登记变化，或者更新从支付处理方所接收的交易信息，或者获取信息以向账户持有人发送通知或利用诸如账户持有人登记变化或新安全码(临时获知的随机模式)之类的相关信息更新支付处理方。
<c>：中央应用服务器3在这种情况下可能通过处理方的网络内的一个或多个分层服务器与支付处理方的数据库服务器4进行通信，以利用账户持有人登记变化或新安全码(临时获知的随机模式)更新支付处理方，或者获取支付处理方所收集的信息或在处理方数据库服务器4内所产生的变化并将其存储在中央数据库服务器1上。
<d>：账户持有人5通过账户持有人所使用的一种或多种通信手段(例如，台式或膝上计算机、智能电话，或者便携式平板计算机)与托管于web服务器8的实例内的web应用进行对接以便创建、删除或修改登记资料或用户偏好，以及从系统获取诸如当前安全码之类的信息。
<e>：web服务器8所收集的信息(例如，登记变化)经由api调用而被传送至中央应用服务器3。web服务器8还向中央应用服务器3发出api调用以从系统获取信息并且将所述信息呈现给账户持有人5。
<f>：中央应用服务器3连接至通知服务器9以便向账户持有人5推送诸如当前安全码的警告，或者有关涉及在账户持有人的登记资料下所注册账户的活动和交易的信息。
<g>：通知服务器向账户持有人5推送诸如电子邮件消息、sms文本消息或移动应用推送警告之类的警告。
<h>：诸如经由商户网站，经由安装在诸如智能电话、平板电脑或手表之类的便携式设备上的移动或远程应用，经由自动电话系统或现场代理，或者经由商户位置的物理终端，账户持有人与商户或收款方7的接口进行交互以便针对商品或服务进行支付交易。
<i>：商户或收款方7通过可应用网络和通道发送账户持有人5所提交的交易信息以由处理方的数据库服务器6进行处理以便批准或拒绝。
<j>：在能够根据本发明进行的交易的情况下，处理方的数据库服务器6与处理法的安全码数据库服务器4进行通信以便验证根据本发明的安全码，所述安全码作为交易授权请求的一部分而被输入。处理方的数据库服务器6还能够将交易信息传输至处理方的数据库服务器4，或者处理方的安全码数据库服务器4能够将账户持有人5所接收或者中央应用服务器3所生成的信息发送至处理方的数据库服务器6。
图2图示了根据本发明的生成安全码的过程，尤其图示了生成组合矩阵的过程，所述组合矩阵将多个账户持有人5(本文有时称之为“用户”)与若干安全码的相应集合进行关联。(出于本公开的目的，每个安全码集合有时在本文可以以各种方式被称作“模式”或“随机模式”或“临时获知的随机模式”)。
在本发明的特定示例中，相应安全码是数学上随机的数字，其具有有限的使用时间或有效期(通常但并非必然地，处于数天或数小时的量级)。所述随机数优选地由真随机数生成器(如本领域已知的)所生成而使得所生成安全码序列的不可预测性最大化。
在本发明进一步的方面，安全码的相应有效期在时间上是连续的，从而实际上，在一个安全码过期之后存在能够被账户持有人所使用的“下一个”安全码(按时间顺序)。有效期可能纯粹是基本上连续的而没有任何时间重合，但是在一个有效期的结束和后续有效期的开始之间形成(与有效期的长度相比)相对小的时间重合(例如，在有效期为一天的情况下的一小时重合)会是有用的。也就是说，一个安全码在“下一个”安全码的有效期开始期间的短期内可以保持有效。提供重合有效性的原因是为了在以下情况下避免所出现的任何消费者(即，用户/账户持有人)的烦恼或挫败感：一个有效期结束之前的短时间(例如，11:30p.m.，其中，在以每天为基础的情况下，有效期在午夜12点结束)进入交易，并且在如本文所公开的信息交换或其他过程中出现了意外延迟，所述延迟将电子支付的实际处理推迟到午夜12点之后，这在理论上要求提交账户持有人的后续安全码。相对短的重合意在平衡一方面确保账户持有人的使用便利性，同时使得同一时间有多于一个的安全码保持有效的安全风险最小化。
如图2和2a所描绘的新矩阵的生成在中央应用服务器3上发起(例如，利用以所安排频率运行的软件工作应用)。出于该非限制示例的目的，假设每日操作，但是其能够被安排为在一天期间运行多次，或者不如每日那么频繁(例如，每三天一次)。
根据本发明的矩阵在一般意义上对要求安全码所保护的访问来使用或以其他方式访问电子实体的用户或其他个人进行分组。通常，给定矩阵包括参与根据本发明的系统的与给定支付处理方相关联的所有用户/消费者/付款方等(例如，与该支付处理方相关联的所有支付卡持有人)。可以作为某种备用而生成附加安全码集合，其可以在需要替换原本指定的安全码集合时(例如，在检测到诈骗活动的情况下)使用。然而，由于如本文所公开的发明的属性，如以下将进一步讨论的，将多余一个的用户与给定安全码集合相关联同样处于本发明的范围之内。
同样，出于说明的目的，本文主要以针对电子支付交易的认证为背景对本发明进行描述，但是其能够应用于针对诸如私人网络、政府机构网站等的电子实体的其他类型的电子认证访问。
通常，首先以随机数填充矩阵以定义相应的安全码集合，其中给定集合中的各个安全码均具有特定的有限有效期，诸如特定一天中的数小时长的时间，或者特定的日历日。每个安全码集合与唯一标识符相关联。一旦以这种方式填充了矩阵，用户就与唯一标识符之一(在本文被称作模式id)相关联从而与匹配该标识符的安全码集合相关联。以此为基础，给定用户在给定时刻与特定安全码集合相关联，并且用户应当用于认证交易的当前有效的码能够相对于可应用的有效期(例如，某个日历日)来识别。
该安全码生成过程优选地在给定有效期内经所有模式id进行循环并且在该有效期内向每个模式id指定新的(诸如4位数的预定长度的)随机数值。在继续生成第三、第四个等集合之前，其接着继续在下一个有效期内针对所有的相应模式id逐个地生成第二随机数值集合。
换言之，该矩阵优选地通过针对每个不同模式id生成随机数而得以组建，并不是第一模式id的完整随机数集合，随后是第二模式id的完整集合，接着是第三个、第四个、第五个，等等。作为结果，如果针对由所使用的随机数生成器(例如，在hsm2中)生成的随机数的序列恰好存在任何类型的可识别的可预测性，则该可预测性将在不同用户间分布而并不处于单个用户的随机数集合内。这在下文中参考图2a进行说明。
如图2中所看到的，每次迭代中该随机数生成的第一步骤是从rng得到新的随机数值101，所述rng诸如硬件安全模块(hsm)2。hsm2最好提供真rng，但是其他基于硬件或软件的任意其他类型的rng——包括伪随机数生成器——都能够被用于该目的。例如，还能够使用提供真随机数的web服务或者针对基于软件或硬件的算法提供接口以生成随机数的第三方二进制应用，或者数据库引擎。
hsm2上的rng产生新的随机数值104，其在步骤106被指定给例如对应于当前迭代的一天(或者任意其他所期望的时间周期)105的当前迭代的模式id104。该示例针对每个相应模式id104为每一天105生成一个随机数值103。然而，多个随机数值能够被指定给每个模式id，所述模式id可以或不必被绑定至特定一天或时间周期，或者能够与比一天更短或更长的时间周期相关联。随机数值还能够与特定的过程标识符相关联，或者与某个事件或过程的发生频率相关联。如图2中示意性图示的，生成随机数值103的过程是迭代的，在第一层级针对一系列模式id，随后递增至下一个有效期(作为示例，本文的有效期是一天)。
图2a是根据本发明的矩阵的示意性表示，其图示了填充矩阵的优选过程。左侧列包含模式标识(id)(简化为范围从0...99999)，其分别与随机数安全码的集合(按照行)相关联。这里，例如每个模式id的每个随机数以逐日有效性为基础(第一天、第二天、第三天等)。针对主光标(处于“第七天”的列的黑色向下箭头)所索引的每一天的列，辅光标(这里例如处于对应于模式id3的行处)经每个模式id进行移动以便填入下一个随机生成的安全码(对应于图2的步骤中的“针对每个模式id”分组)。因此，在图2a中，最后生成的码是(模式id3；第七天)处的0166。辅光标随后将移动至下一个模式id(即，4)并且针对(模式id4；第七天)生成新的随机码，并且针对第七天中的所有模式id以此类推，随后主光标将前进至下一天的列(即，第八天)(对应于图2中由“针对每一天”所指示的下一迭代层级)，并且随机数指定将重复进行。结果，如以上所提到的，如果针对任何给定用户(即，针对任何给定模式id)的随机化安全码是不适宜的，则可能出现的随机数生成中任何模式或随机性缺失在按行排列的方向都将并不明显。
将要注意的是，能够针对矩阵生成与消费者/用户相比更多的模式(即，安全码集合)。这能够允许“备用的”代码集合例如能够在安全码的初始集合看上去被盗用的情况下由消费者用作替换代码集合。例如，相对于图4而参见下文有关重新指定新的模式id的公开。
然而，依据本发明也能够想到生成与消费者/用户相比更少的模式的情形。在这样的情况下，多于一个的用户可能与一个给定模式id相关联。例如，即使严格地讲，两个用户可能因此知道另一个人的安全码，但是要记住将用户指定至模式id对于用户而言实际上是不透明的，因此由于实际上任一个用户一般都非常不可能知道他正在与另一个用户“共享”他的安全码集合，甚至他更不可能知道具体哪个用户拥有同样的安全码，所以安全性风险依旧很低。
视情况，随机数值的生成可与要从矩阵排除的数值列表互相参照或者以其他方式与之进行比较。例如，某些文化上具有冒犯性或者以其他方式敏感的数值可以被排除(诸如西方文化中的“13”或者一些东方文化中的“4”)。如可能需要的，可以针对排除列表对rng生成的数值进行校验，并且如果找到，则对rng进行新的调用以生成替换数值，直至所生成的数值不在所述排除列表上。
在该示例中，一旦完整的安全码(临时获知随机模式)的矩阵被填充，它就接着被发送以便在步骤107存储在中央数据库服务器1上，所述中央数据库服务器1在步骤108将所述矩阵加载到数据库表格中。所述矩阵也能够以其他格式进行存储，诸如被存储在文件系统中或者以象形表示形式来存储。
出于所描述过程的目的，如该流程图中所描绘的那样生成的临时获知随机模式的矩阵随后将被用来为每个所登记的账户持有人指定模式id，如图3中的步骤211所描绘的，而使得新的随机码能够被用于账户持有人5所发起的交易。
为了支付处理方能够支持根据本发明的支付交易，相同版本的矩阵(因为可能偶尔更新或以其他方式被修正)在步骤109被分发给每个参与的支付处理方。优选地，每个参与的支付处理方的矩阵版本在被分发之前以针对该支付处理方唯一的方式进行散列。经唯一散列的矩阵随后在本地被每个支付处理方加载在与该支付处理方相关联的安全码数据库服务器4上。
该矩阵中的随机数数值优选地利用安全散列算法(sha)进行散列，所述算法被行业标准和规范证明是安全且可靠的。例如，依据本发明的该方面能够使用sha-512。包括sha-512在内的多种安全散列算法例如在2012年3月公布的联邦信息处理标准公布文本(federalinformationprocessingstandardspublication)180-4中有所公开，其内容在相关专利局将允许的范围内通过引用结合于此。为了在矩阵中的随机数数值被向外传送至支付处理方或银行之前对它们进行散列，每个支付处理方例如被指定以在步骤110(例如，从hsm2)获得的唯一散列盐值(hashsalt)111或者以其他方式与之相关联。该散列盐值111还以安全且加密的方式被传输给每个相应的支付处理方以便在交易授权过程中使用。如本领域已知的，“散列盐值”是给定散列过程的数学基础。应当注意的是，使用给定散列算法关于给定串(例如，本发明的数字安全码之一)所应用的散列盐值将始终产生所述串的相同版本。
使用相应的唯一散列盐值111(即，每个相应支付处理器的唯一散列盐值)，针对不同的支付处理方创建相同矩阵的唯一散列副本(步骤112)，每个矩阵包含随机数的经唯一散列的表示形式。因此，所生成被指定给每个模式id的实际随机数集合仅在中央数据库服务器1中明码保存以便将它们传输至所注册的账户持有人。每个支付处理方将仅在它们相对应的安全码数据库4的实例上保存这些数值的“它的”不同散列表示形式(步骤113)，其不同于任意其他支付处理方的散列表示形式。
图3图示了根据本发明的账户持有人5如何在系统中进行的登记的过程。账户持有人5发起登记请求。如果账户持有人登记资料已经存在201，则账户持有人5能够在步骤212继续向已有资料注册新的/附加账户。否则，如果需要新的账户持有人登记，则账户持有人5在步骤202继续输入创建登记资料所需的信息。该信息例如可以包括全名、账单地址、联系人信息(诸如移动电话号码或电子邮件地址)和通知偏好。所述信息在中央应用服务器3由子过程203进行验证从而核实所输入的账户持有人信息。该子过程203可以包括地址验证、身份验证服务，以及其他类型的了解你的客户(know-your-customer)验证步骤。
一旦所输入的账户持有人信息通过了验证步骤(步骤204)，就在205生成临时的随机字母数字或数字代码并且通过所输入的电子邮件地址或移动电话号码经由通知子过程800将其发送给账户持有人，以便验证账户持有人5有权访问所述电子邮件地址或者与所提供的移动电话号码相关联的物理设备。一旦在步骤206接收到临时代码(其具有有限使用期限)，账户持有人5就在步骤207被要求将其重新传回到登记应用服务，它随后被中央应用服务器3所认证。如果账户持有人所输入的临时代码与步骤205所生成的匹配并且在时间上仍然有效(步骤208)，则所收集的账户信息就被用来创建账户持有人资料(步骤209)并且在步骤210被存储在中央数据库服务器1上。当登记资料在中央数据库服务器1中被创建时，模式id104(例如，参见图2a)在211被指定给新创建的账户持有人资料，账户持有人5将在安全码矩阵中利用所述模式id104而被识别。如图4中所描绘的，这因此将驱动账户持有人5将被呈现的安全码。账户持有人随后将根据他们的通知偏好而经由子过程800(参见图9)被通知以资料创建结果，所述通知偏好可以包括至所提供移动电话号码的sms文本消息，至所提供电子邮件地址的电子邮件消息，或者移动应用推送通知中的一种或多种。该账户持有人登记结果通知可以包括与服务进行交互所必需的信息，包括但并不局限于唯一账户持有人资料标识符以及在进行电子支付交易时使用的代码。
一旦账户持有人资料存在，账户持有人5就能够随后继续将一个或多个账户与他们的账户持有人资料进行关联(212)。账户注册过程212可以包括识别新账户213(诸如借记、信贷或支票账户)并且输入账户信息(步骤214)。对于银行账户而言，这包括账户号码和银行的汇款路径号码(rtn)。对于卡账户而言，这可以包括完整卡号(通常为15-16位，有时更少而有时更多)、过期日期、印在物理卡上的任意形状或形式的验证码，或者emv(europay、mastercard和visa)情况下的数字验证码，或者可应用情况下的虚拟卡。
中央应用服务器3验证所输入的账户信息是否有效。使用将卡片的银行识别号码(bin)或账户的aba汇款路径号码(rtn)映射到相对应银行或支付处理方(已经登记支持根据本发明的系统的互相参照的金融机构和/或支付处理方)的常规可用资源，在215检查给定账户参与本发明的系统的资格。
如果账户合格(步骤215)，则该系统继续至子处理216来验证被正当输入的账户属于该账户持有人，否则所述账户持有人经由通知子处理800而被通知所述账户无法被添加。账户验证步骤可以包括针对(例如，由支付处理方或发卡方或者另一第三方所操作的)验证账户持有人信息的web服务的调用，或者可以包括地址验证和cvv验证的零美元价值(zerodollarvalue)授权请求，或者授权机构所提供的用来验证账户真实性的任意其他服务。在银行账户的情况下，该验证过程可以包括一系列小额试验存款，例如1和99美分之间随机数额的两笔存款，账户持有人随后必须通过确认收到所述数额来进行验证。
在账户在217被验证为有效地属于账户持有人5之后，该系统继续在218向账户持有人资料添加账户，并且在219将其存储在中央数据库服务器1上。随后在步骤220通过在中央数据库服务器1上查找221而获取到账户的支付处理方或银行id信息。利用该id信息222，该系统随后在223通过调用支付处理方所提供的api或者被传送并加载到支付处理方的系统上的文件或者支付处理方提供用来更新它们的系统从而记录给定新账户被添加的任意其他手段而将该信息发送至支付处理方的数据库服务器。被传送至支付处理方的信息包括账户持有人的登记资料信息，特别是与之相关联的模式id，从而允许所述处理方在未来的交易授权请求中验证当前安全码矩阵中的账户持有人的安全码。
最后，账户持有人经由通知子过程800而得到通知并且在224接收到账户注册的确认。
当前所公开的用于生成和管理安全码的方法和系统能够在电子支付安全和金融交易安全以外的领域中使用。例如，工地、实验室、办公室等可以实施本发明以每天向雇员发送安全码而作为附加的认证或访问控制机制。在不同领域，根据本发明的代码都能够被实施为账户持有人的身份的附加证明从而应用于来自商户、服务提供方或其他类型的政府或私有机构的信贷、新账户或服务。
如上文所描述的，账户持有人能够进行注册以接收根据本发明的每日安全码以便在单一领域或跨许多(特别是许多相关)领域使用。例如，账户持有人可以注册来自两个不同发行方/处理方的信用卡，以及相对于账户持有人的工作场所访问控制系统进行注册，等等。具有多个如以上所描述的注册资料的账户持有人可能想要选择将这些资料一起分组在一个或多个群组中，分别具有根据本发明的相应的安全码。也就是说，账户持有人因此能够使用每天针对所述账户持有人所注册的所有不同实施方式有效的单个(或者与要求安全码的领域的总数相比较少的)安全码。
在这种实施方式分组的示例中，安全码注册资料(scrp)是个人用户以及要求安全访问的单一金融账户或非金融账户的单个实例。非金融账户包括但并不局限于网站访问、计算机登录画面或物理访问控制情形。在本发明中，scrp是单个账户持有人在单个处理方数据库中的资料。
为了能够更容易地使用同时减少所要记住并使用的安全码的数量，多个信用卡、借记卡、金融账户和安全登录能够按照期望进行分组。一旦被分组，该群组中的所有scrp就将具有相同的模式id，并且每天将会接收到相同的安全码。以这种方式，例如，个人能够针对他们所有的借记卡和信用卡接收到相同的安全码。
所述分组并不必被局限于单一个人。例如，家庭能够选择将全家的所有信用卡和借记卡放入相同分组，并且因此全部家庭成员每天都将针对他们所有的信用卡和借记卡拥有相同的安全码。
在另一个示例中，拥有公司信用卡的企业雇员能够被分组在一起并且因此将每天针对他们每人各自的公司信用卡接收到相同的安全码。在另一个示例中，军事班/排/部队等的所有成员能够每天接收到相同的安全码作为确认他们排中的成员资格的方式。
个人可以是若干群组的成员，以及具有并非任何群组的成员的scrp。针对每个群组以及非群组scrp，个人将接收到唯一的安全码。例如，一个人可以将其所有信用卡、借记卡放在“家庭群组”中；将其单一的企业信用卡放在“公司群组”；并且将其支票账户设为“未分组”。在这种情况下，这个人根据本发明每天将接收到三个唯一安全码。
分组标准可以由系统或者每个账户持有人或者一个或多个群组的特权管理员所预先设定的规则来确定。例如，自动分组规则可以包括，如果两个账户持有人资料共享相同的电子邮件、电话或其他之前验证的联系人信息，则每天针对那些匹配资料所产生并传递的代码将被分组并且被同步为相同。
在另一个示例中，所注册的账户持有人被给予发起与另一个账户持有人的资料进行分组的邀请请求的能力，以便在授权账户持有人或群组管理员授权的情况下每天针对特定实施方式接收到相同代码。
图3a图示了在账户持有人的资料要与另一个账户持有人或分组自动或按需地被分组在一起时所引入的高阶步骤。
当分组指定过程231被发起时，如果是由账户持有人按需请求232，则发起针对加入所请求群组的授权的请求233。如果账户持有人被授权234加入所请求群组，则账户持有人的登记资料实例在步骤235被指定给所请求群组，并且发起通知过程800以向群组中的所有相关的利益相关人通知指定过程。然而，如果账户持有人在步骤234被认为没有被授权加入所请求群组，则不采取动作并且账户持有人按照步骤236而保留在当前所指定的群组。在这种情况下同样触发通知过程800以向利益相关人警告访问所请求群组的非授权尝试。
在步骤232中加入所述群组的请求被识别为非按需(即，它是自动的)的替选路径上，在步骤240执行用于针对账户持有人找出自动资料分组规则的过程。如果在步骤241找到了与所设立标准相匹配的规则，则账户持有人的登记资料实例在步骤242被自动指定至现有群组并且相应地在步骤800发送通知。否则，不采取动作并且账户持有人按照步骤236而保持在当前或新指定的群组中，并且在步骤800中发起通知。
随后在图3b至3g中图示出以上所提到群组的一些示例。例如，图3b图示了具有单个安全码注册资料——在该实例中是creditcardp1c1——的单个个体pi，其自身属于它自己的群组g1。这意味着账户p1c1并不与任何其他注册账户共享安全码。换言之，该模式id及其相关联的安全码并非有意被匹配。
应当注意的是，每个安全码注册资料(scrp)被指定以模式ip，所述模式id在任意给定时间段被指定以特定的安全码。由于可用的安全码数量有限，所以即使该数字非常大，在任意给定时刻两个不同模式id将具有为它们所指定的相同安全码也是相当可能的。
图3c图示了具有三个不同信用卡scrpp2c1、p2c2、p2c3以及一个借记卡scrpp2d1的单个账户持有人p2，上述所有scrp都在单个群组g2中被分组在一起。这意味着根据本发明，在这些scrp下所注册的所有四个账户每天都将接收到对应于群组g2的相同安全码。这样的情形的实际示例是想要他钱包中的所有卡片每天都接收相同安全码的账户持有人。
图3d示出了具有自身处于群组g3中的一个信用卡scrpp3c1以及另外两个信用卡scrpp3c2、p3c3和一个借记卡scrpp3d1的单个账户持有人p3，后三个scrp在群组g4中被分组在一起。这示出了其中账户持有人可以选择一个或多个scrp被分组在一个组中而将一个或多个其他scrp分组在单独分组中从而两个群组每天接收单独安全码的示例。例如，账户持有人可以使得他被分组在一起的所有个人信用卡和借记卡每天接收对于它们全部有效的单一安全码，而用于其商务信用卡和借记卡账户的单独群组则接收与针对他的个人账户有效的那个不同的安全码。
图3e示出了其中属于不同个体账户持有人的不同scrp也能够被分组在一起以每天接收相同安全码的示例。该特征例如可以被家庭、企业、组织或社会团体中想要针对在不同安全码注册资料下的账户集合每天接收相同安全码的成员所使用。在该示例中，属于账户持有人p4的信用卡scrpp4c1以及账户持有人p5的scrpp5c1和都属于账户持有人p6的scrpp6c1和p6d1全部被注册在单个群组g5下。每个账户持有人p4、p5和p6因此每天接收相同的安全码。
如上文之前所表明的，安全码能够在电子支付安全和金融支付安全以外的领域中使用。图3f图示了具有访问码scrp的多个个体账户持有人p7-p11，所述访问码scrp例如可以是用来物理访问办公楼或者虚拟访问安全公共或私人网络上的网站或网络的安全码。在该图示中，分别属于个体账户持有人p7、p9、p10和p11的所有访问码scrpp7a2、p9a1、p10a1和p11a1在单个群组g7中被分组在一起以便每天接收相同的安全码。与此同时，个体账户持有人p7还持有属于单独群组g6的单独scrpp7a1，所述群组g6与属于不同个体账户持有人p8的另一个scrpp8a1所共享。只要scrpp7a1和p8a1都与相同群组g6相关联，它们也每天接收相同的安全码。在该示例中，单个账户持有人p7持有所注册并且处于具有不同个体账户持有人的不同群组g6和g7中的多个scrp。这样的示例的具体应用可以是想要扮演两种角色——例如不同网络上的“受限用户”和“管理员用户”——并且针对每种角色需要与每个群组中的其他个人所共享的不同安全码的个人。
这里所说明的另一个领域被称作社交码，其可以是被个体账户持有人用来访问社交群组、在其中享有特权或者简单地被辨识或识别为属于所述社交群组的安全码，所述社交群组例如秘密社交俱乐部。图3g图示了多个个体账户持有人p12、p13、p14、p15和p16，它们均具有全部处于相同群组g8中的各自社交码scrpp12s1、p13s1、p14s1、p15s1、p16s1，这保证了它们每天全部接收相同的安全码。
图3h示出了scrp以及它们被指定的群组能够如何以表格形式进行表示并且存储在数据库中以便实施本发明的示例。表格t1保存scrp的每个示例，其所属账户(实体)的pid，以及所指定的群组的群组id(例如，gl、g2、g3等)。表格t2a、t2b和t2c均是保存哪些安全码模式的模式id在给定日期周期(即，有效期)中被指定给每个群组的群组id的表格的分段。该日期周期由“从日期”和“至日期”所表示，其指示所指定的模式id有效的每个周期的开始和结束日期。每个模式id随后在表格t3中进行表示，所述表格t3为每一天指定不同的安全码day1code、day2code等。以这种方式，每一天都能够通过遍历这些表格查找scrp被指定给哪个群组群组id而确定哪个安全码对于特定scrp是有效的；随后查找哪个模式id在该给定日期/时间周期期间针对该模式id有效，以及随后查找哪个安全码在该特定日期/时间周期(该示例中为一天)内被指定给该模式id。群组id和日期的组合始终给出相同的安全码(日期/时间周期变化的短期内的两个码)，这独立于模式id如何针对每个群组id进行转动。因此，共享相同群组id指定的两个scrp被保证每天也共享相同的安全码。
图4描述了在以规律的基础为注册账户持有人提供他们相对应的(多个)有效安全码的过程期间所进行的步骤。
为了接收与账户持有人的资料相关联的当前有效的安全码，账户持有人5能够请求安全码或者经由从中央应用服务器3所驱动的自动推送自动接收它。
如果账户持有人5请求了所述码，则从账户持有人5发送请求301，例如经由设备所安装的应用，或者通过调用进而与中央应用服务器3处的api进行通信以获取账户持有人的至少一个当前安全码的web应用(诸如来自支付处理方或者账户持有人的在线银行网站页面的api调用)，或者通过向系统提供的sms简短代码提供移动发起的sms文本消息，所述sms简短代码将文本消息指向中央应用服务器3，所述中央应用服务器3随后发起返回至账户持有人5的sms响应(包括当前安全码)。
来自账户持有人5的请求应当包含识别所述账户持有人的资料id302，以及识别从其发起所述请求的设备或应用的源标识符。资料id应当唯一地识别与账户持有人5相关联的登记资料。设备的源标识符则可以是用来发送请求的移动电话号码，或者移动应用标识符，或者是绑定至用来执行(即，发送)所述请求的设备的任意其他id。优选地，所述请求包含源标识符(源id)和资料id以便验证所述请求的真实性。
为了找出账户持有人的资料(步骤303)，中央应用服务器3调用中央数据库服务器1中的过程以查找(步骤304)账户持有人资料。为了使得认证安全性最大化，该过程首先验证源id是已知与所注册用户或账户持有人相关联的授权设备/输入源。如果在305使用所接收的源id找到了账户持有人资料，并且账户持有人在请求中所指示的资料id针对所识别的账户持有人资料是有效的(步骤306)，则中央应用服务器3继续满足所述安全码请求(步骤307)。否则，如果资料id并不匹配所识别的账户持有人资料，则通知子过程800被用来向账户持有人通知接收到无效的安全码请求。子过程800可以使用账户持有人资料中所指定的一种或多种通知偏好，诸如sms消息或电子邮件消息。
账户持有人5也可以能够对从系统接收的通知作出回复，或者发起请求(例如，在被怀疑为诈骗活动的情况下)更新或替换当前安全码。在这种情况下，中央数据库服务器1向相对应的账户持有人的登记资料指定以不同的模式id104，并且将该更新推送至所有参与的支付处理方。账户持有人随后被通知以(步骤800)与新的模式id(以及实际上新的基本矩阵)相关联的新的当前安全码。
对于当前安全码的自动定期“推送”，请求312被自动发送以查找中央数据库服务器1中有资格被提供以经更新的安全码通知的账户持有人5(步骤313)。这些更新的频率能够由账户持有人所选择，如可以是一天中发送更新的时间。一旦建立了需要自动更新的账户持有人的群组，就运行子过程(在图4中被标记为“针对每个账户持有人”)以向那些账户持有人中的每一个通知他们的当前安全码。
为了(在以上任一种情况下)向账户持有人发送通知或警告，中央应用服务器3发起请求307以查找给定账户持有人的安全码(步骤308)。从账户持有人的登记资料id获取相对应的模式id，并且从临时获知随机模式矩阵或表格取出在当前有效期内(例如，当前一天)对应于该模式id的安全码。账户持有人5随后被通知(800)以当前安全码。
当前安全码的该通知能够简单地是在web或台式机或移动应用请求或者按照在账户持有人的设备上的web浏览器插件应用上的返回。该安全码还能够基于账户持有人之前所设立的通知偏好来传递，例如经由至针对账户持有人所注册并验证的移动电话号码的sms文本消息，或者电子邮件消息，或者移动应用推送通知。
在本发明的变化形式中，为用户提供新的安全码的过程还可以整合定期变化的模式id(即，并非仅更新给定安全码集合内的安全码)而使得用户因此实际上与完全新的安全码集合相关联。例如，在定期基础上(例如，每7天)，能够执行将规律地将每个用户重新指定至新的模式id的子过程(本文未示出)。例如，如果模式id是数字的，则rng(可能但并不一定与hsm2中使用的相同)能够被用来在用户将被重新指定的可用模式id范围内生成随机的新模式id。
定期重新指定模式id最好进一步提高了任何给定安全码与任何给定用户的关联的随机性，并且因此有助于系统抵御攻击、模式推导，以及其他访问用户的安全码和/或预测未来安全码的努力。
图5以高阶图示了账户持有人5例如在进行购买时针对商户或收款方支付界面所进行的电子支付授权请求。这里主要关注的是调用交易授权子过程500，其随后相对于图6更为详细地进行描述。
在购买或发起类似的电子支付交易请求时，账户持有人5提交发起支付授权请求所必需的信息(步骤401)以完成与商户或收款方7的交易。
假设交易涉及到之前已经与账户持有人5的资料相关联的账户，则账户持有人5一般将当前有效的安全码包括为交易请求的一部分。例如，安全码可以以与支付卡的常规cvv2码相同的方式但是作为其替代而提交，或者替代类似cvv的其他卡信息，或者与卡号串联，或者由电子令牌或代理数字来体现，或者在专门用于接收根据本发卖给你的安全码的单独字段中。
针对支票支付，本发明的安全码能够在支票的备忘录字段中例如利用支票的备忘录字段中的字段指示符来指定。例如，根据本发明的4位安全码能够以一个单词或符号作为前缀。它也可以在两侧以预定符号或字符来定界，例如“+4567+”中的“+”。
可替换地，所述安全码能够与印刷在支票上的支票号码连在一起，以有效地创建根据预定义且普遍接受和预期的格式的扩展支票号码。例如，随例如456的安全码一起使用的支票号码101实际上可以在通常的支票号码字段中印刷为“101456”。该支票随后可以由接收银行利用扩展支票号码“101456”以ach文件中的常用方式进行处理。
在其他示例中，所述安全码能够由账户持有人以在输入字段中写入的以手工方式或者向在场的人或语音识别系统以口头方式单独给出。商户随后将该信息包括在ach请求文件中(例如，在附录或条目细节字段中)。
商户或收款人7具有接收账户持有人5所提交的信息的常规支付界面。根据账户持有人5使用卡还是支票402，并且如果商户在线连接，则所述系统立即将电子支付授权请求405发送至相关支付处理方(参见图1中的6)，或者调度、形成ach传输请求403并且随后经由之前在商户或收款方7和相对应的支付处理方、接收银行或其他金融机构之间所建立的通道将其发送至相关支付处理方以处理所述ach请求。这可以包括支付网关服务提供方、支付处理网络、联邦储备银行或电子支付网络，或者商户或收款方7与处理方或接收银行之间的任意其他服务或服务器。
支付处理方随后通过接收卡支付请求或者作为处理ach交易请求404的一部分而发起下文关于图6详细描述的交易授权子过程500。该子过程500批准或拒绝所述交易授权请求，并且结果406在步骤407以适应商户或收款方7的需求的方式而被发回商户或收款方7。进而，商户或收款方7在账户持有人界面409向账户持有人5通知授权结果。
图6图示了交易授权的子过程500。当依据图5发起卡或支票支付处理400时，支付处理方或接收银行在502决定所使用的交易类型和账户是否有资格进行跟进本发明的处理。支付处理方通过查询包含必要信息的数据库表格或配置文件(例如，位于与支付处理方相关联的服务器之一上，诸如安全码数据库服务器4或数据库服务器4)以确定所述交易是否有资格进行跟进本发明的处理，或者通过向托管于支付处理方的网络内或者(相对)远程地处于图1所示的中央系统的api发起调用来进行该操作。还能够通过检查在交易授权请求有效载荷——例如包括在iso8583字段之一中——或者所接收的nachaach文件上所包含的指示符来确定资格。
如果交易在502并未具有根据本发明的进行处理的资格，则支付处理方在509继续正常(即，并不使用本发明的安全码的常规的)授权批准过程。否则，处理方的数据库服务器6向在处理方的安全码数据库服务器4(其可以处于处理方的网络本地或者处于远程位置)所实施并安装的应用或处理发出调用从而发起交易的验证过程。处理方的数据库服务器6与处理方的安全码数据库4进行对接，例如通过发出远程存储过程的调用或者扩展存储的过程，或者与安装在处理方的数据库服务器6上有权访问处理方的安全码数据库4的组件对接的sqlclr。可替换地，处理方的数据库服务器6与本地或远程的服务或api进行通信，后者进而有权访问处理方的安全码数据库4。
对从处理方的数据库服务器6作为授权请求的一部分所接收的信息进行检查以确定所讨论的账号是否与存储在处理方的安全码数据库4上的有效账户持有人登记资料相关联。从处理方的数据库服务器6所接收的交易数据被用来查找账户持有人的登记资料id和相对应的模式id104以获取与账户持有人以及所使用的卡或账户相关联的有效安全码。在根据本文所描述的实施方式的一个示例中，该交易数据可以包含账户别名604(参见图7)而不是账户持有人所使用的实际的卡号或银行账户号码(以进一步限制敏感金融信息的传播)。这种意义下的账户别名是支付处理方原则上在内部基础上所使用的卡号或银行账户号码的表示形式，以便使得卡号或银行账户号码的传播最小化。它并不一定被账户持有人所知。通常，支付处理方使用令牌或代理号码，但是根据本发明，可以使用卡号或银行账户号码(虽然并非优选)或者资料id或模式id自身。
一旦在交易授权请求中所使用的账户被确认为已登记(503)，则支付处理方的安全码数据库服务器4还确定该账户是否被锁定(504)并且因此针对交易授权请求不合格。账户可以应被账户持有人的请求被锁定，或者基于系统所检测到的诈骗活动的迹象而被永久或临时锁定。该检测可以是所执行的内部分析和算法，或者是第三方诈骗或风险管理规则系统，或者诸如可商业获得的
如果账户在504并未被标记为被锁定，并且安全码已经被正确包括在交易请求501中(如在505所确定的)，则支付处理方的安全码数据库服务器4继续在子过程600验证所接收到的安全码(参加下文图7的讨论)。如果子过程600在506返回安全码有效的指示，则随后为用于验证交易细节的子过程1100(参见图12)。
注意505的“安全码存在？”判定。将要注意的是，即使安全码在步骤505并不存在(即，作为交易授权请求的一部分而提交)，该过程仍将直接分支到子过程1100以基于其他因素来验证交易的细节，并且最终前往并不包括本发明的安全码处理的授权处理(在509)。以这种方式，即使并未在特定交易中查到根据本发明的安全码，仍然能够使用如本文所公开的其他安全功能。
如果验证交易细节子过程1100确定支付交易请求是有效的508，则处理方的安全码数据库服务器4成功返回至处理方的数据库服务器6，处理方的数据库服务器6随后在509继续交易授权请求批准的正常进程。
根据本发明的验证过程可以仅是电子支付交易授权过程的一部分，而使得根据本发明的验证过程的成功可能不一定导致支付处理方最终对交易的授权。
然而，根据验证交易细节子过程1100，如果安全码验证在506失败或者交易在508如果被认为无效，则将无效交易尝试在509被记入日志以便进行报告和记录留存，并且账户持有人得到通知而使得能够在适宜情况下采取纠正动作。被发送至账户持有人的(多个)经验证设备的通知在交易是由账户持有人正当尝试的情况下可以包括有效安全码，而使得其能够利用正确的安全码再次尝试。向账户持有人通知无效尝试还为账户持有人5提供了采取措施来防止所讨论账户的欺诈使用的机会，包括快速且轻易地锁定该账户上的任何进一步交易尝试的可能性，例如通过简单地回复所接收到的带有锁定指令900的通知。该通知交换能够经由账户持有人的资料上经验证的登记的移动电话号码上的sms文本消息来进行，或者经由按照在账户持有人所拥有的设备上并且被正确注册且先前被认证的应用来进行。
在支付处理方被建议在509继续批准过程或者在511拒绝支付授权请求之后，处理方的数据库服务器6可以为系统发送回最终的交易授权结果以便进行记录以及在子过程700进一步分析。
图7图示了如在图6中的交易授权子过程500期间所发起的根据本发明的通过其对安全码进行验证的子过程600。子过程600确定账户持有人5所提交的安全码为有效还是无效。
处理方的安全码数据库服务器4在601接收验证所接收安全码的请求，所述安全码由账户持有人5作为交易授权请求500的一部分所提交。安全码601随后在602使用行业所接受的安全散列算法(sha)——诸如sha-512——进行散列从而在603获得经散列的所接收安全码。更具体地，使用与在原本生成矩阵时对矩阵中的安全码进行散列的散列盐值相匹配的特定于同一支付处理方的散列盐值111对所接收的安全码601进行散列，从而如在支付处理方处保存的散列盐值111被用来镜像了在生成矩阵时通过其对矩阵中的安全码进行散列的散列算法。
使用表示与被验证交易相关联的支付账户的账户别名604，安全码数据库服务器4在步骤605查找相对应的模式id。模式id606随后被用来在步骤609搜索存储在处理方的安全码数据库服务器4中的本地存储的散列矩阵版本，以查找与所找到的模式id606相对应的散列值。安全码群组中对应于模式id606的正确安全码数值通过利用支付交易的日期和时间607以及账户持有人选择的所存储的截止时间608而被确定，所述截止时间608确定了相应的安全码应当何时被更新(即，在给定安全码的有效性过期时支持后续的一个)。该查找操作609的结果获得与所接收账户别名604相关联的当前安全码的散列参照版本610。该散列值随后在步骤611以已知方式与安全码的散列提交版本603进行比较。
应当注意的是，所提交安全码和(矩阵中的)所存储安全码之间的认证比较是在两个码都被散列的同时进行。也就是说，由相应支付处理方所保存的矩阵中的安全码始终以经散列(即，被模糊)的形式来保存。此外，散列是“单向的”——其无法被逆转从而获得清晰形式的基本信息。因此，即使在处理方的安全码数据库被攻击或以其他方式被潜入的情况下，安全码也进一步得到保护，这是因为仅有安全码矩阵的散列版本位于相应支付方的本地。这种方式的散列有助于解决支付处理方的不诚信雇员或者可能以其他方式有权访问消费者安全码的其他内部人员的潜在问题。
为了对ach或支票交易进行授权，可能仅在授权请求中指定了(例如，支票的)日期而非时间(考虑到诸如邮件延迟或顺序处理的延迟)。在这种情况下，所提交的安全码将相对于矩阵上在那一天器件有效的每一个安全码进行验证，而无论截止时间如何。由于实际的交易批准可能在支票的准备和提交之后进行，可能必须要查找在处理的当前日期前多达1、7、30或者可能90天的日期的安全码。
如果所接收到的散列值603和来自特定于支付处理方的矩阵的本地版本的散列值610相匹配(步骤612)，则该过程指示所提交的安全码是有效的(613)。否则，该系统在614指示该代码是无效的。
图8图示了在图6中所提到的子过程700的步骤(记录并分析交易结果)。该数据例如可以与在支付处理方一侧所接收并处理的交易请求同时或接近同时地被接收。否则，信息会堆积在例如在每天结束时定期生成的报告中。
在交易授权子过程500完成之后，可以由处理方的安全码数据库服务器4在701形成请求以记录交易细节。
在步骤702，在处理方的安全码数据库服务器4确定交易是否要求或者以其他方式有资格进行实时或即时通知。需要通知的一个示例为：在交易中提交了无效安全码，其他方面能够根据本发明进行处理的情况下，要求这种针对账户持有人5的通知。作为结果，通过调用中央应用服务器3所展现出的api而向该服务器发出消息。
当中央应用服务器3在703接收到交易通知时，在步骤704确定是否必须向账户持有人5发送通知。如果要求通知，则运行用于通知账户持有人的子过程800(参见以下的图9)。
可选地还能够使用常规算法和其他标准分析来进行交易诈骗分析705。诈骗分析可能由被设计为在某些数量或集合的条件被满足的情况下指示诈骗的内部规则集合所组成，或者分析可以被送至外部的第三方诈骗或风险管理服务(这里未示出)。可选地，可以采取动作来确保所讨论的支付方法，包括自动锁定基本账户或者使得相关的当前安全码无效。
类似于步骤704，步骤706考虑账户持有人是否必须关于诈骗分析结果得到通知，并且如果是，则随后为诈骗通知子过程707。子过程707在本文并未详细解释，但是总体上类似于(下文所描述的)通知子过程800，但是具有具体的消息有效载荷。
如果交易在702并未被标记为用于立即或实时通知，则交易在708被标记或调度以包括在将随后在709在批处理等中被发送至中央应用服务器3的报告中。这通常表示批文件，其具有自最后的批文件被产生以来所接收到的新的交易细节的增量。中央应用服务器3随后对从处理方的安全码数据库4所接收的批文件进行处理，并且在711发送它们以便存储在中央数据库1上。所接收的交易细节在步骤712被记录以便未来例如为了商业智能处理、汇报或计费而进行查看、记录留存和分析。
图9图示了用于向账户持有人5发送通知的子过程800的步骤。其中，子过程800例如在本文参考图3、4和8而有所提及。
当通知要被推送至账户持有人5时，在801向中央应用服务器3发送具有消息有效载荷的请求(也就是，要求通知的具体细节或信息802)。例如，当安全码要在通知中被推送至账户持有人5时，请求801包含所述安全码、识别账户持有人5的信息，以及所要发送的通知的类型的可能信息或指示。
中央应用服务器3在803与中央数据库1进行通信以便(在804)查找账户持有人的通知传递偏好。所选择的偏好通知传递方法的列表805例如可以包括电子邮件(或者具体通知库集)、sms、经由app的推送通知、寻呼机消息等中的一个或多个。
可选地，能够由中央应用服务器3在806请求通知模板以便能够以所期望的方式对通知进行格式化。如果能够应用，则能够在807和808可能基于之前所指定的账户持有人偏好而在中央数据库1上针对账户持有人5查找模板信息。
例如，就此意义而言，用于传送当前安全码的通知模板可以是“dear{first-name},yoursecuritycodefortodayis{security-code}”。通知中的可变内容(如所指示的，诸如账户持有人的姓氏)例如能够从以上所讨论的通知细节802中拉取，并且在必要情况下在步骤809替换到模板之中。替换步骤809创建实际的消息内容810，诸如“dearmaddy,yoursecuritycodefortodayis364”，其例如在步骤811经由所期望的(多种)通信方法(电子邮件813、sms815或app推送通知817)被发送至账户持有人5。包括其模板的通知可以为多种语言之一，并且设想到使用(例如，英语以外的)其他字符。
图10图示了根据本发明的用于有选择地锁定或解锁所注册支付账户的子过程900。该上下文中所提到的“锁定”或“解锁”意在表示账户当前要根据本发明的所使用的可用性(或不可用性)。
子过程900允许账户持有人5通过与单个应用或服务进行对接来管理多个机构所发出且有多个支付处理方或接收银行所处置的多个账户。在一个示例中，在一个或多个账户存在可疑的诈骗使用的情况下或者在相关联的支付卡或支票簿已经被错放的情况下，或者甚至在父母对于未成年人针对(多个)账户的访问的控制的背景下，账户持有人可能想要锁定他的一个或多个账户。
当账户持有人5在901决定锁定(或解锁)他的一个或多个注册账户时，账户持有人5发送请求，所述请求例如由与其登记资料相关联的资料id902、所讨论的(多个)账户的标识(903)以及可选地在其上发起所述请求的设备的id(例如，账户持有人5所使用的智能电话的移动电话号码)所组成。所述请求被发送至中央应用服务器3并且在904被验证。一旦所述请求是有效的，就在中央数据库1上查找账户持有人的资料(步骤905)。
依据本发明的账户标识(账户id)通常是与账户持有人的每个相关账户相对应的简写且容易记住的表示形式，并且被用来帮助账户持有人在根据本发明进行交易时在他的资料中的其各个账户之间加以区分。账户id可以是账户持有人5所给出的数字或者字母数字单词或短语。例如，它可以是序号或字母，或者是字母和数字的组合，以便例如识别账户持有人的资料中的“visacard4572”或“bofabankaccount1721”。该账户id例如也可以是卡号或银行账户号码的一部分。账户id也可以是关键字或数字，例如“all”，作为账户持有人的资料下的所有账户都要被锁定/解锁的快捷指示符。
一旦账户持有人资料被定位并且所指示的账户是有效的(在906)，则存在用于改变/更新所讨论的每个账户的锁定/解锁状态的迭代过程(图10中由“针对每个账户”所指示的步骤群组)。
针对被锁定/解锁的每个账户，中央应用服务器3在907开始按照账户持有人5所请求的将中央数据库1中的账户的状态变为锁定或解锁(908)的过程。随后，中央应用服务器3在909呼叫支付处理方或其他相关金融机构，这对应于在中央数据库1进行查找910。一旦定位了相关的支付处理方911，中央应用服务器3就发送更新请求而使得处理方的安全码数据库4更新账户的状态，这在913执行。
使用账户持有人通知子过程800，账户持有人5被通知以所请求的锁定/解锁操作的结果，并且账户持有人5接收到确认914。
用于锁定(多个)账户的请求可以受制于某些条件而作出，诸如固定时段期间的一次锁定，在所设置时段的定期锁定，或者在一天中的某些时间期间锁定。例如，账户持有人5可以请求账户被锁定，从而在工作日的7:00pm至9:00pm的数小时期间和/或在2016年3月29日至2016年4月5日的一周期间防止任何相关联的交易得到批准。在一些情况下，可能指定的可能仅是按照天的时段(而不是按照时间)，诸如在银行结算在某天进行的情况下。
所述条件例如还能够应用于某些商户、商户类型(例如，不包括电影院)或者地理区域。
图11图示了关于被发送至支付处理方和相关金融机构的通知的子过程1000中的步骤，其与图10中的子过程900稍有类似。
除了锁定或解锁账户的请求之外，账户持有人5例如可能希望向其相关支付处理方之一通知相对应的支付卡已经丢失或被盗，或者提前指示账户持有人5将有国际旅行计划(而使得诈骗分析能够相应地有所调整)。在另一个示例中，账户持有人5可能希望例如针对用于支票账户的新的支票簿，或者在卡损坏的情况下针对替换支付卡而传输请求。
子过程1000在账户持有人5连同资料id1002以及所讨论账户的一个或多个账户id1003一起提交请求或其他通信1001时开始。中央应用服务器3在1003处理请求1001，并且在1004验证该请求(使用用户和账户id)。一旦被验证为有效，就在1005在中央数据库1查找账户持有人的资料。
在通知请求1001在1006被验证为有效时，该处理经每个所请求账户进行迭代(如跨中央应用服务器3、中央数据库1和处理方的数据库服务器6并且被标记为“针对每个账户”的步骤群组所指示)，并且被识别以更新或调度它们的状态或偏好。账户id可以是账户持有人5所给出的数字或字母数字单词或短语而使得系统识别账户持有人的资料中的账户。这里应用如上文在图10中所讨论的用于构建账户id的相同考虑。
针对所指定的每个账户，中央应用服务器3在步骤1007在中央数据库1调用过程而以账户持有人5所请求的方式改变账户的状态(步骤1008)。在步骤1009，中央应用服务器3请求对应于所讨论账户的支付处理方或银行，这与中央数据库1处以获得相关的支付处理方1011的查找步骤1010相对应。一旦针对所讨论账户识别出相关支付处理方1011，中央应用服务器3就向支付处理方的数据库服务器6发送请求1012以更新账户的状态(参加那步骤1013)。
账户持有人5随后被(使用通知子过程800)通知以所请求的(多个)操作的(多个)结果，并且适时地接收所述请求已经被执行的确认1014。
最后，图12图示了如例如在子过程500(以上的图6)中关于交易授权所提及的子过程1100(验证交易细节)的步骤。
当子过程500在处理方的安全码数据库4中发起时，或者在需要相对于之前在账户持有人的登记资料中所建立的任何可应用规则对交易的细节进行验证时，在处理方的安全码数据库4运行该用于验证交易细节的子过程1100。
给定资料id1101，账户持有人的登记资料被找到(1102)并且确定是否存在任何应用的账户持有人所建立的交易规则(1103)。如果没有可应用的交易规则，则子过程1100退出，这指示交易细节过程已经“通过”(即，完成)。
否则，使用作为针对该子过程的输入而通常从处理交易授权子过程500的支付处理方所接收的交易细节，可应用规则(例如，交易金额/限额1106、商户相关细节(诸如商户名称或者任意可应用的商业商户目录编码)1107、经常性交易标志/指示符1108，或者任意其他交易相关细节1109，诸如本地交易日期和时间，以及所购买的产品或服务的信息)被浏览并且在1105被验证为能够应用。
更为详细地，如本文所设想到的交易验证的示例包括但并不局限于：
交易金额限制：账户持有人5可以针对注册账户上所尝试的任何给定交易预先定义最大值或上限。例如，账户持有人可能想要拒绝在账户持有人的登记资料中所注册的给定信用卡上任何例如超过$500.00的交易尝试。
商户或商户类别限制：账户持有人可以选择在被尝试的情况下阻止针对某些商户或商户类别的交易。相反，账户持有人可以指定他的一个或多个账户仅能够在某些特定商户或者针对某些商户类别来使用。账户持有人还能够指定注册账户要针对其专门使用的商户或类别的列表，并且拒绝在任意其他商户或商户类别尝试的任何交易。例如，商户持有人可以选择所要使用和批准的账户仅购买某些物品，或者在某些位置或商户类别进行购买，如杂货或汽油，或者可能想要限制某些商户类别，诸如拒绝在酒类专卖店尝试进行的任何购买。
经常性交易规则：账户持有人可以决定是否同意或拒绝来自某些商户或账单方的经常性交易，或者指定有多少经常性交易应当被同意以及以何种频率同意。账户持有人可以选择针对所注册账户的所有经常性交易针对注册都被拒绝，除非在设置于账户持有人的登记资料上的交易验证规则上有所指定。例如，账户持有人可以指定账户应当仅来自来自具体电力公司的每季度不高于$1200.00的金额以及来自有线电视提供方每月$150.00或更低金额的经常性交易。账户持有人可以设置这些规则为有效直至被去除，或者指定过期日期、所同意分期付款的数量。
也可以指定其他规则或者这些的任意组合。例如，经常性交易规则可以包括商户类别限制或者交易最大金额。
在1105检查了交易验证规则之后，如果交易通过了1110处的所有可应用规则，则处理在1104返回“通过”结果。否则，其返回“失败”结果1111，并且账户持有人还可以可选地经由通知子过程800而得到验证失败的通知。
该实施方式的变化还可以涉及到在规则验证失败的情况下与账户持有人的实时通信，以便使得账户持有人主动参与到交易批准过程之中。例如，如果接收到经常性ach支付并且账户持有人尚未针对该特定类型的支付设置规则，则账户持有人例如能够通过自动或现场代理电话呼叫或sms文本消息或者移动应用推送通知而得到通知，以便从账户持有人请求批准或确认拒绝，并且可能在此时针对来自该特定收款方或账单方的任意其他交易尝试设置经常性交易规则。在交易授权请求期间还能够进行与账户持有人的其他实时通信，大多数情况下是在诸如支票或ach支付之类的离线交易的处理期间，以便例如使得账户持有人纠正已经被输入的无效安全码。
虽然上文出于说明和解释本发明的目的参考某些特定示例对本发明进行了描述，但是必须要理解的是，本发明并不仅参考那些示例的具体细节而被限制。更具体地，本领域技术人员将会轻易理解的是，能够在优选实施例中进行修改和开发。
虽然上文以电子支付交易为背景对本发明进行了描述，但是所公开的概念能够更为一般地被应用于针对敏感电子网络或者要求减少基本安全码泄漏的用户认证的其他电子实体的安全电子访问。例如，本发明能够在税务机构事务中被应用于用户认证从而允许在税务申报或者关于如退税等问题与税务机构进行交互时进行用户认证。更一般地，其能够允许用户方便地以与上述所描述的多个金融机构所使用的相同方式而使用单一安全码来与例如多个政府机构(税务、执法部门等)进行交互。其能够距所访问实体被远程包含和运行(例如，经由api来访问)，并且例如将接收到资料id、请求方id(对应于用户寻求访问的实体，并且与之前针对支付处理方标识的描述中类似)、请求方的密码，以及用户所提交的安全码。
虽然上文出于说明和解释本发明的目的参考某些特定示例对本发明进行了描述，但是必须要理解的是，本发明并不仅参考那些示例的具体细节而被限制。更具体地，本领域技术人员将会轻易理解的是，能够在优选实施例中进行修改和开发而并不因此超出本发明的范围。