基于移动OTP的交易的授权的制作方法

基于移动otp的交易的授权
1.相关申请的交叉引用
2.本技术要求2019年7月3日提交的第16/502,117号美国申请的优先权，所述美国申请的全部内容以引用的方式并入本文中。
技术领域
3.本公开大体上涉及电子交易，且更具体地说，涉及使用移动一次性密码(motp)授权交易。


背景技术：

4.在使用支付卡(例如，信用卡、借记卡或储值卡)的支付交易期间，重要的是验证持卡人对账户的所有权以避免各种问题，例如未授权的使用。支付方认证是验证持卡人对账户的所有权的方法。在认证持卡人后，授权持卡人进行的交易也很重要。
5.消费者支付装置被呈现给商家或由销售点终端访问的交易被称为“有卡(card present)”交易，因为支付装置与商家或终端处于相同的物理位置。
6.除有卡交易之外，消费者还可在支付装置与商家或终端不处于相同物理位置的情况下发起交易，而实际上通过通信网络将相关数据提供给商家(被称为“无卡(card not present)”交易)。例如，消费者可以通过经由例如因特网的网络将支付数据从远程位置提供给商家而发起涉及购买产品或服务的无卡交易。此类型的交易通常使用个人计算机或膝上型计算机等计算装置发起。无卡交易还可使用移动电话等移动支付装置发起或执行，在此情况下，与商家或数据处理系统的通信可能通过蜂窝或无线网络发生。因此，交易的支付信息可以使用支付装置和销售点终端提供，或者可以使用远程定位的支付装置以及其它方法提供给商家。
7.一种在有卡交易期间认证持卡人对账户的所有权的方法涉及商家代表取走持卡人的卡，通过支付卡终端刷卡以验证账户状态和信用额度可用性，然后查看卡背面的签名是否与购买方的签名匹配。签名的比较提供账户所有权的认证。如果商家遵循此类型交易的特定准则，则商家将获得授权金额减去折扣和费用后的支付保证。
8.另一方面，“无卡”交易，例如通过移动装置、通过邮件或通过电话在线发生的交易，涉及不向商家保证的支付。在线交易包括例如通过因特网进行的交易。不提供保证主要是因为支付方未在此类非面对面交易中被认证，从而允许许多风险伴随“无卡”交易。此类风险涉及例如对在线商家的支付交易退款、对商家和持卡人两者进行欺诈、银行异常项目处理费用增加，以及人们越来越认为在线或通过移动装置购买商品和服务不安全等问题，这可能使一些消费者远离在线购买。风险的其它实例包括未授权使用被盗账户信息在线购买商品和服务、伪造卡账号以进行欺诈性在线购买，以及从网络流量中提取明文账户信息。
9.例如使用静态密码、一次性密码(otp)或atm pin之类用于认证持卡人对无卡交易的卡的标识的现有技术需要电信网络支持，因此，交易经常由于电信网络的延迟或故障而被拒绝和/或超时。当在山区或网络连接较差的地方无法完成交易时，尤其如此。
10.因此，需要不易受电信网络中延迟或故障的影响的安全和有效的方式来认证无卡交易。
11.本公开部分的此背景技术中所公开的信息仅用于增强对本公开的大体背景技术的理解，而不应视为表示此信息形成本领域的技术人员已经知道的现有技术的承认或任何形式的暗示。


技术实现要素：

12.在一些非限制性实施例或方面，提出一种授权交易的计算机实施的方法。所述方法包括由目录服务器从收单方系统接收例如支付认证请求(pareq)消息等交易消息以用于认证和授权交易。交易消息包括移动一次性密码(m-otp)。在一些非限制性实施例或方面，m-otp由持卡人使用配置在持卡人装置中的发行方移动应用程序生成。在一些非限制性实施例或方面，m-otp由持卡人输入到商家系统中。商家系统生成包括m-otp的交易消息，且将交易消息提供到收单方系统以用于认证和授权。所述方法还包括将交易消息发送到发行方系统以用于认证和授权。此后，从发行方系统接收响应消息，所述响应消息包括授权和认证的结果。所述方法还包括经由收单方系统将响应消息提供到商家系统。
13.在一些非限制性实施例或方面，提出一种目录服务器。目录服务器被配置成促进授权交易。目录服务器包括一个或多个处理器和与所述一个或多个处理器通信地耦合的一个或多个计算机可读介质。一个或多个处理器被配置成从收单方系统接收包括移动一次性密码(m-otp)的交易消息。在一些非限制性实施例或方面，m-otp由持卡人使用配置在持卡人装置中的发行方移动应用程序生成。在一些非限制性实施例或方面，m-otp由持卡人输入到商家系统中。商家系统生成包括m-otp的交易消息，且将交易消息提供到收单方系统以用于认证和授权。目录服务器还被配置成将交易消息发送到发行方系统以用于认证和授权。此后，目录服务器还被配置成从发行方系统接收响应消息，所述响应消息包括授权和认证的结果。此外，目录服务器还被配置成经由收单方系统将响应消息提供到商家系统。
14.在一些非限制性实施例或方面，提出一种用于授权交易的计算机实施的方法。所述方法由商家系统执行。所述方法包括接收移动一次性密码(m-otp)作为输入以用于发起交易。m-otp由持卡人使用配置在持卡人装置中的发行方应用程序生成。所述方法还包括生成交易消息，所述交易消息包括m-otp和指示交易消息包括所述m-otp的唯一标识符。交易消息与不包括m-otp的其它类型的交易消息不同。所述方法还包括将包括m-otp的交易消息提供到收单方系统。收单方系统在交易消息中包括授权请求。此外，收单方系统将交易消息发送到目录服务器，所述目录服务器被配置成将交易消息发送到发行方系统以用于认证和授权。发行方系统基于认证和授权生成响应消息并发送到目录服务器。目录服务器经由收单方系统将响应消息发送到商家系统。所述方法还包括接收响应消息并适当地指示持卡人。
15.前述概述仅仅是说明性的，并且并不旨在以任何方式作为限制。除了上文描述的说明性方面、实施例和特征之外，通过参考图式以及以下详细描述，另外的方面、实施例和特征将变得显而易见。
附图说明
16.在附图的图中以实例而非限制的方式示出本公开的示例实施例，并且其中相似的附图标记指代相似的元件，并且在附图中：
17.图1示出根据本公开的一些非限制性实施例或方面的用于执行交易的示例性平台；
18.图2示出根据本公开的一些非限制性实施例或方面的实施基于m-otm的认证和授权的示例性核心系统架构；
19.图3a和3b示出根据本公开的一些非限制性实施例或方面的用于生成m-otp的示例性发行方移动应用程序；
20.图4a和4b示出根据本公开的一些非限制性实施例或方面的提供m-otp的示例性商家结账页面；
21.图5是描述根据本公开的一些非限制性实施例或方面的由商家系统促进的基于m-otp的支付授权的流程图；
22.图6是描述根据本公开的一些非限制性实施例或方面的由目录服务器促进的基于m-otp的支付授权的流程图；
23.图7a示出根据本公开的一些非限制性实施例或方面的包括构成支付方认证请求(pareq)消息的格式的示例性表；
24.图7b-7e示出根据本公开的一些非限制性实施例或方面的包括与mti标识符的第一位置、第二位置、第三位置和第四位置相关的数据字段的示例性表；
25.图8a示出根据本公开的一些非限制性实施例或方面的在支付交易期间不通过3d轨道发送的基于m-otp的消息的示例性流；
26.图8b示出根据本公开的一些非限制性实施例或方面的在支付交易期间通过3d轨道发送基于m-otp的消息的示例性流；并且
27.图9示出用于实施与本公开一致的实施例的示例性计算机系统(900)的框图。
28.本领域的技术人员应了解，本文中的任何框图表示体现本发明主题的原理的说明性系统的概念视图。类似地，应了解，任何流程图表、流程图、状态转换图、伪代码等表示可基本上在计算机可读介质中表示并且由计算机或处理器执行的各种过程，无论是否明确示出此类计算机或处理器。尽管每个附图出于示出清楚的实例的目的而示出了特定实施例，但其它实施例可以省略、增加、重新排序和/或修改图中所示的任何元件。
具体实施方式
29.在本文档中，词语“示例性”在本文中用于意指“充当实例、例子或说明”。本文中描述为“示例性”的本发明主题的任何实施例或实施方案不一定解释为比其它实施例优选或有利。
30.虽然本公开容许各种修改和替代形式，但是本公开的特定实施例已经借助于实例在图式中示出并且将在下文中详细描述。然而，应理解，并不旨在将本公开限于所公开的形式，而是相反，本公开旨在涵盖属于本公开的范围内的所有修改、等效物和替代方案。
31.术语“包括(comprises/comprising)”或其任何其它变体旨在涵盖非排它性包括，使得包括一系列组件或步骤的设置、装置或方法不仅包括那些组件或步骤，还可包括并未
明确地列出的或此类设置、装置或方法固有的其它组件或步骤。换句话说，在没有更多约束的情况下，系统或设备中在“包括(comprises
…
a)”之后的一个或多个元件不排除系统或设备中其它元件或额外元件的存在。
32.通常，当持卡人已认证且交易由发行方系统(发行方银行或可信第三方系统)授权时，交易就完成了。通常，生成两个请求消息，例如，支付认证请求(pareq)消息和支付授权请求消息。商家系统生成pareq消息，并且收单方系统生成支付授权请求消息。首先由发行方系统处理pareq以认证持卡人。在认证期间，由发行方系统生成otp。otp通常被发送到持卡人的注册手机号和/或注册电子邮件。然后，持卡人将otp输入商家结账页面。将从持卡人接收的otp与生成的otp进行比较以认证持卡人。在认证成功后，生成支付授权请求消息，所述支付授权请求同样被提供到发行方系统。在授权期间，基于包括账户余额、交易的安全性和此类详情的许多因素来验证交易。当生成两个独立的消息以用于认证和授权时，完成交易所花费的时间更长。并且，由于必须处理两个独立的消息，因此处理复杂性增加。此外，由于依赖于持卡人的电信网络，因此此类交易容易发生故障。
33.本公开的实施例涉及用于认证和授权基于移动一次性密码(m-otp)的交易的方法和系统。持卡人可以在安装在持卡人装置上的发行方移动应用程序中生成m-otp。将所生成的m-otp输入可供持卡人使用的商家结账页面中以用于完成交易。一旦m-otp被输入，商家系统就生成交易消息，所述交易消息包括所述m-otp和指示交易消息包括所述m-otp的唯一标识符。交易消息包括支付认证请求(pareq)。收单方系统在交易消息中包括支付授权请求并发送到目录服务器。目录服务器将包括pareq的交易消息和支付授权请求发送到发行方系统以用于认证和授权。发行方系统生成包括交易消息的认证和授权的结果的支付认证响应(pares)消息。目录服务器接收pares消息并经由收单方系统将其发送到商家系统。
34.图1描述用于执行交易的平台(100)的概述。平台(100)作为服务提供给参与发行方、账户持有人和商家。描述与在线支付交易相关的平台(100)的实施方案。在线支付交易的描述涵盖支付交易和特定消息流。本公开涉及具有例如用于认证持卡人的otp的双因素认证的安全特征的在线交易。鉴于在线交易描述整个说明书。然而，本公开不限于在线交易，并且可以应用于提供例如otp的双因素认证的任何类型的交易。
35.平台(100)被设计成在一方无法实际验证声称是特定账户所有者的另一方的身份的交易期间认证和授权持卡人(101)账户所有权。例如，当可信方(通常是发行方系统)(107)为了第三方的利益而认证持卡人(101)的身份时，平台(100)可用于各种交易。众所周知，可信方通常承担向第三方认证持卡人(101)的法律责任。
36.在在线购买中，交易流程开始于持卡人(101)在设置于计算单元(103)的商家结账页面中输入卡(102)的详情。商家系统(104)接收卡(102)的详情并生成交易消息以用于认证持卡人(101)。商家系统(104)经由收单方系统(105)将交易消息路由到目录服务器(106)。目录服务器(106)将交易消息发送到发行方系统(107)以用于认证持卡人(101)。发行方系统(107)验证卡(102)的详情并映射到持卡人(101)的账户。此外，发行方系统(107)生成otp，所述otp通常通过电信网络在注册的移动装置(经由sms)和注册的电子邮件(经由因特网)上提供给持卡人(101)。在收到otp后，持卡人(101)将所述otp输入商家结账页面。商家系统(104)经由目录服务器(106)将otp发送到发行方系统(107)以用于验证。发行方系统(107)进一步验证otp并认证持卡人(101)。在认证成功后，收单方系统(105)生成包括与
交易相关的信息的支付授权请求消息，以供发行方系统(107)授权交易。发行方系统(107)验证支付授权请求消息中存在的信息并授权交易。对成功授权的确认由发行方系统(107)提供。所述确认由商家系统(104)提供给持卡人(101)。
37.图2示出平台(100)的核心系统架构(200)的一些非限制性实施例或方面。核心系统架构(200)包括三个域：可信方域、互操作性域和第三方或请求方域。可信方域和第三方域定义其内为分别完全或至少部分由可信方或第三方控制的组件的功能领域。互操作性域定义组件可以供可信方、第三方以及例如服务组织之类的其它方利用的功能领域。
38.可信方域包括主要由可信方控制的组件。可信方的实例为称为发行银行的向消费者发行支付卡的金融机构。具体地说，发行方或卡发行方将从卡供应商接收的新卡个性化，然后向其客户发行这些卡。个性化还可以由卡供应商或个性化局执行。除金融机构之外，发行方可以是任何合适的发行实体，例如电信网络运营商、服务协会、商家或其它组织，或甚至代理发行方行事的代理人。
39.第三方或请求方域包括主要由第三方和/或请求方控制的组件。第三方可以是请求认证账户持有人的身份的任何方。例如，第三方可以是希望认证声称是卡账户所有者的人的身份的商家。第三方可以是收单方，其为将商家登记在支付方案中并管理商家的账户的金融机构。收单方还将信息从在线商家路由到电信网络。在其它实施例中，商家可以将信息直接路由到电信网络。
40.互操作性域可以由因特网支持，并且包括供可信方和第三方两者使用的组件。
41.在本公开中，可信方域还在下文中被称为发行方系统(107)。发行方系统(107)包括发行方持卡人模块(201)、登记服务器(202)、访问控制服务器(acs)(203)和账户持有人文件(204)。发行方系统(107)内包括其它组件，具体取决于系统使用的特定使用领域。例如，在支付交易中，域中的每一个中存在额外组件，以便认证持卡人(101)在支付交易方面的身份。
42.在一些非限制性实施例或方面，登记服务器(202)是管理持卡人登记到发行方系统(107)的计算机，方法是(例如，经由网页界面)呈现将由账户持有人回答并由可信方验证的一系列问题。如图2所示，发行方系统(107)操作登记服务器(202)。然而，在一些非限制性实施例或方面，例如的服务组织可以代表发行方系统(107)操作登记服务器(202)。发行方系统(107)可以在登记过程期间使用外部实体提供的联网交互式“身份认证服务”来帮助验证账户持有人的身份。
43.在一些非限制性实施例或方面，acs(203)是具有为账户认证服务注册的账户持有人数据库的计算机。acs(203)包括每个账户持有人的账户和密码信息。在账户认证交易期间，acs(203)将数字签名的收据提供给认证请求方，控制对发行方系统(107)的访问，并且验证账户持有人对认证服务的参与。在一个或多个实施例中，卡发行方或例如的服务组织可以为可信方(也被称为收单方系统(105))操作acs(203)。虽然账户认证服务不需要使用任何额外持卡人软件，但是可以部署任选的账户持有人软件和硬件。额外账户持有人软件可以支持额外认证技术，例如数字证书、集成电路卡(例如，芯片卡)和芯片卡读取器。
44.账户持有人文件(204)是可信方管理的数据库，其用于存储与用发行方系统(107)成功登记的账户持有人相关的信息。发行方持卡人模块(201)由可信方控制且包括关于账
户持有人的信息。此类信息涉及账户信息、持卡人(101)使用的服务等。发行方持卡人模块(201)内的一些信息可用于将账户持有人登记到发行方系统(107)中。
45.收单方系统(105)请求认证账户持有人。在一些非限制性实施例或方面，商家系统(104)管理有利于认证协议的商家插件软件(205)。商家插件软件(205)是集成到商家(104)的网站中的软件模块。商家插件软件(205)被编程或配置成用于生成具有m-otp的交易消息。此外，商家插件软件(205)可以在交易消息中包括pareq消息。收单方插件软件(206)管理收单方系统(105)。在一些非限制性实施例或方面，如果商家插件软件(205)尚未在交易消息中包括pareq消息，则收单方插件软件(206)从商家插件软件(205)接收交易消息并包括pareq消息。此外，收单方插件软件(206)还在交易消息中包括支付授权请求消息。此后，收单方插件软件(206)将交易消息发送到互操作性域以用于认证和授权。
46.在一些非限制性实施例或方面，互操作性域包括目录服务器(106)。目录服务器可以由因特网支持，并且包括供发行方系统(107)和收单方系统(105)两者使用的组件。目录服务器(106)被配置成将认证请求和/或授权请求从收单方系统(105)路由到特定acs，例如acs(203)。目录服务器(106)由卡方案管理器或例如visa的服务组织操作。互操作性域还可由因特网以外的网络支持。
47.在一些非限制性实施例或方面，认证过程适用于持卡人(101)在线购物、将商品添加到“购物车”、前往在线商家结账页面并完成在线商家的结账表单的情境。认证过程可以在持卡人(101)决定购买所需产品或服务之后进行，例如，在持卡人(101)点击“购买”按钮之后进行。认证过程还可以在持卡人(101)支付交易中的各种其它时间开始。认证过程主要通过利用已并入支付网络的若干点中的软件而以透明模式对持卡人(101)进行。目录服务器(106)用认证服务验证持卡人(101)和持卡人的金融机构的参与。然后，创建窗口，在所述窗口中，持卡人(101)可以通过输入持卡人(101)的装置中生成的m-otp来确认其身份。在一些非限制性实施例或方面，m-otp可以在发行方移动应用程序中生成(图2中未示出)。在一些非限制性实施例或方面，与发行方系统(107)相关联的任何应用程序可以代表发行方金融机构生成m-otp。m-otp以及交易详情在交易消息中被发送到发行方系统(107)。由于m-otp不需要网络支持，因此不同于常规系统，pareq消息和支付授权请求消息可以包括在交易消息中。如果确认持卡人(101)的身份，则将支付信息和持卡人(101)的认证通知发送回商家系统(104)。然后，由商家系统(104)处理支付交易。例如，商家系统(104)可以将订单确认消息发送到持卡人的浏览器。
48.图3a和3b示出用于生成m-otp的发行方移动应用程序(301)。如图所示，发行方移动应用程序(301)可以是用于生成m-otp的应用程序。在一些非限制性实施例或方面，发行方移动应用程序(301)可以是用于生成m-otp的专用应用程序，或者可以与发行方银行应用程序集成，并且可以提供界面以用于生成m-otp。在一些非限制性实施例或方面，m-otp是基于时间(时间同步)的otp。在一些实施例中，m-otp还可以被称为时间一次性密码(t-otp)。在一些非限制性实施例或方面，t-otp使用基于基于散列的消息认证码(hmac)的otp算法。hmac是使用散列技术编码的算法。在m-otp中，当前时间被散列以生成m-otp。在一些非限制性实施例或方面，m-otp还包括时间数据。对于给定时刻，可以使用唯一算法生成m-otp。当给出m-otp用于认证时，可以在认证端(在此情况下，为发行方系统(107))处使用相同的算法(由持卡人(101)生成)，以基于由持卡人(101)生成的m-otp中的时间数据生成m-otp。如
果两个m-otp(一个由持卡人(101)生成)而另一个由发行方系统(107)生成)匹配，则持卡人(101)被成功认证。m-otp与其它otps相比的优点是可以离线生成m-otp。图3a示出第一应用程序页面，其中发行方移动应用程序(301)可以提供用以生成m-otp的选项。如图所示，按钮可以设置在持卡人装置(103)的用户界面(ui)上。按钮可以是物理按钮或触敏按钮。
49.图3b示出显示所生成的m-otp的第二应用程序页面。在一些非限制性实施例或方面，发行方移动应用程序(301)可以实施基于hmac的otp算法。在一些非限制性实施例或方面，在发行方移动应用程序(301)中实施的唯一算法在发行方系统(107)中实施。当持卡人(101)点击按钮时，发行方移动应用程序(301)生成m-otp并在持卡人装置(103)的ui上显示。在一些非限制性实施例或方面，m-otp是数字密码(例如，“148261”)。在一些非限制性实施例或方面，m-otp还可以是字母数字密码(例如，“pass123”)。在一些非限制性实施例或方面，m-otp还可包括特殊字符(例如，“！”、“@”、“％”等)。在一些非限制性实施例或方面，m-otp可以具有4-8个数字和/或字符。在一些非限制性实施例或方面，m-otp中的数字和/或字符的数量可以根据发行方系统(107)遵循的标准。在一些非限制性实施例或方面，m-otp在生成之后被复制到剪贴板。可以将复制的m-otp粘贴在适当的认证表单中。
50.图4a和4b示出根据本公开的一些非限制性实施例或方面的提供m-otp的商家结账页面。图4a示出请求卡和持卡人详情的示例性商家结账页面。图4a和4b中的图示不应解释为限制。图示仅为实例，并且图4a和4b中描述的方面可以应用于任何结账页面。如图所示，结账页面包括包含金额和日期的交易详情。在一些非限制性实施例或方面，结账页面还可包括商家详情和关于交易的其它必要详情。在一些非限制性实施例或方面，商家插件软件(205)与结账页面相关联。如图4a所示，第一表单(401)请求持卡人(101)输入详情，例如持卡人(101)的姓名、卡号、到期数据、安全码和认证类型。当持卡人(101)输入卡号时，商家插件软件(205)可以标识与卡相关联的互操作性服务提供方(例如，)。在输入卡的详情和与持卡人(101)相关联的详情之后，结账页面提供用以选择认证类型的选项。现有的结账页面提供包括otp和静态密码(3d安全密码)的认证类型。根据本公开，商家结账页面提供包括m-otp的额外认证类型。当持卡人(101)选择m-otp选项作为认证类型时，结账页面被导航到第二表单(402)，如图4b所示。
51.如图4b所示，第二表单(402)接收m-otp。持卡人(101)可以生成m-otp，如图3a和3b所示。在一些非限制性实施例或方面，如果m-otp是使用发行方移动应用程序(301)生成的且m-otp被复制到剪贴板，则持卡人(101)可以粘贴m-otp。或者，持卡人(101)可以在第二表单(402)的字段中手动键入m-otp。在由持卡人(101)输入m-otp之后，提交按钮使得m-otp提交到商家插件软件(205)。
52.以下方法描述由商家系统(104)执行的步骤。图5是描述根据本公开的一些非限制性实施例或方面的由商家系统(104)促进的基于m-otp的支付授权的流程图。
53.如图5所示，方法(500)可包括一个或多个步骤。可以在计算机可执行指令的总体上下文中描述方法(500)。通常，计算机可执行指令可以包括执行特定功能或实施特定的抽象数据类型的例程、程序、对象、组件、数据结构、过程、模块和功能。
54.描述方法(500)的次序并非旨在理解为限制，并且可以按任何次序组合任何数量的所描述方法框来实施所述方法。另外，在不脱离本文描述的主题的范围的情况下，可以从所述方法删除个别框。此外，所述方法可以在任何合适的硬件、软件、固件或其组合中实施。
55.在步骤(501)，商家系统(104)从商家结账页面的第二表单(402)接收m-otp。与m-otp一起，商家系统(104)还接收第一表单(401)中输入的卡的详情、持卡人(101)的详情。
56.在步骤(502)，商家系统(104)生成包括m-otp的交易消息。在一些非限制性实施例或方面，根据iso 8583标准生成交易消息。iso 8583定义交易消息结构。现在参考图7a，其示出iso 8583消息格式的实例。如图7a所示，根据iso8583生成的交易消息可包括消息类型标识符(mti)、主要位图、次要位图和数据元素。mti是描述每个消息类别和功能的四位数数字字段。iso 8583标准的版本很少，它们是：iso 8583：1987、iso 8583：1993和iso 8583：2003。四位数中的第一位数表示iso 8583的版本。这在图7b中示出。如图所示，当四位数的第一位数为0时，版本为iso 8583：1987。同样，当四位数的第一位数为1时，版本为iso 8583：1993，而当四位数的第一位数为2时，版本为iso 8583：2003。
57.图7c示出与mti的第二位数相关联的字段。如图所示，第二位数可以取值0到9。如图7c中可见，对于值0和9，针对iso保留mti字段。同样，图7d示出与mti的第三位数相关联的字段。如图7c中可见，对于值8和9，针对iso保留mti字段。
58.在一些非限制性实施例或方面，商家系统(104)可以在交易消息中包括唯一标识符，从而指示交易消息中m-otp的存在。在一些非限制性实施例或方面，四位数中的第二位数可以指示交易消息中m-otp的存在。例如，第二位数中的值0可以定义为指示m-otp。在另一实例中，第二位数中的值9可以定义为指示m-otp。
59.在一些非限制性实施例或方面，四位数中的第三位数可以指示交易消息中m-otp的存在。例如，第三位数中的值8可以定义为指示m-otp。在另一实例中，第三位数中的值9可以定义为指示m-otp。
60.在一些非限制性实施例或方面，对于第四位数的所有值，定义字段。因此，可能无法使用第四位数标识m-otp。图7e示出与mti的第四位数相关联的字段。
61.在一些非限制性实施例或方面，唯一标识符是mti四位数代码。
62.在一些非限制性实施例或方面，位图是指示交易消息中可能存在或不存在哪些数据元素的字段。交易消息包括称为主要位图的至少一个位图，所述位图指示存在数据元素1到64中的哪些。也可以存在次要位图作为数据元素一，并且次要位图指示存在数据元素65到128中的哪些。并且，第三位图可用于指示字段129到192的存在或不存在。在一些非限制性实施例或方面，m-otp可以容纳在数据元素的前1-64位中，或数据元素的65到128位中。因此，可以更新主要位图和次要位图以指示交易消息中的m-otp。位图的值指示m-otp是存在于1-64位中还是存在于65-128位中。
63.数据元素是含有交易信息的所有字段。iso8583：1997含有多达128个数据元素(消息将具有多达2个位图字段)。较晚的版本含有多达192个数据元素(消息将具有多达3个位图字段)。每个字段(数据元素)具有特定的含义和格式。在一些非限制性实施例或方面，数据元素还可包括m-otp。例如，可以使用数据字段46、47、48、55-63、105-119。在一些非限制性实施例或方面，字段128用于常规系统中的消息认证码。根据本公开，字段128可用于m-otp。
64.在一些非限制性实施例或方面，商家系统(104)可以在交易消息中包括pareq消息。在一些非限制性实施例或方面，商家系统可以不在交易消息中包括pareq消息。
65.返回参考图5，在步骤(503)，商家系统(104)将在步骤(502)中生成的交易消息提
供到收单方系统(105)。在一些非限制性实施例或方面，如果商家系统已在交易消息中包括pareq消息，则收单方系统(105)进一步在交易消息中包括支付授权请求消息。收单方系统(105)将包括pareq消息和支付授权请求消息的交易消息提交到目录服务器(106)。目录服务器(106)被配置成将交易消息发送到acs(203)以用于认证和授权。acs(203)接收交易消息并初始地验证m-otp。在一些非限制性实施例或方面，acs(203)基于mti字段中的值而确定必须使用m-otp认证交易消息。此外，acs(203)使用交易消息中的位图值标识m-otp。此后，acs(203)检取m-otp以用于认证。在验证m-otp时，acs(203)使用交易消息中包括的时间数据在发行方系统(107)中本地生成m-otp。acs(203)使用的用于生成m-otp的算法应与发行方移动应用程序使用的算法相同(301)。如果生成的m-otp与接收的m-otp匹配，则成功认证交易消息。如果生成的m-otp与本地生成的m-otp不匹配，则认证失败。在认证成功后，acs(203)从交易消息检取交易详情并授权交易。在一些非限制性实施例或方面，交易信息包括以下各项中的至少一个：持卡人的主账号、处理代码、交易金额、交易日期和时间、收单方系统标识码、货币代码、发行方系统标识码和认证模式，所述认证模式包括m-otp、由发行方系统生成的一次性密码(otp)、静态密码和生物特征模式信息。授权可以如现有系统中所执行来执行。此后，acs(203)基于认证和授权生成支付认证响应(pares)消息。pares中的字段可以基于认证和授权的成功。
66.在一些非限制性实施例或方面，目录服务器(106)能够标识m-otp，检取m-otp，并且将m-otp连同交易消息一起提供到acs(203)。
67.在一些非限制性实施例或方面，将pares消息提供到目录服务器(106)，所述目录服务器将pares消息路由到收单方系统(105)。收单方系统(105)继而将pares消息发送到商家系统(104)。
68.在步骤(504)，商家系统(104)从收单方系统(105)接收pares消息并在商家结账页面上向持卡人(101)呈现适当消息。
69.现在参考图6。以下方法描述目录服务器(106)执行的步骤。图6是描述根据本公开的一些非限制性实施例或方面的由目录服务器(106)促进的基于m-otp的支付授权的流程图。
70.如图6所示，方法600可包括一个或多个步骤。可以在计算机可执行指令的总体上下文中描述方法600。通常，计算机可执行指令可以包括执行特定功能或实施特定的抽象数据类型的例程、程序、对象、组件、数据结构、过程、模块和功能。
71.描述方法600的次序并非旨在理解为限制，并且可以按任何次序组合任何数量的所描述方法框来实施所述方法。另外，在不脱离本文描述的主题的范围的情况下，可以从所述方法删除个别框。此外，所述方法可以在任何合适的硬件、软件、固件或其组合中实施。
72.在商家系统(104)已经生成包括m-otp的交易消息并且假设执行了步骤(501)-(503)(直到交易消息被提供到收单方系统(105)为止)之后，执行以下步骤。
73.在步骤601，目录服务器(106)从收单方系统(105)接收包括m-otp的交易消息。在一些非限制性实施例或方面，目录服务器(106)能够使用交易消息中存在的标识符将包括m-otp的交易消息与不包括m-otp的其它类型的交易消息区分开来。在一些非限制性实施例或方面，接收的交易消息仅包括pareq消息。在一些非限制性实施例或方面，交易消息包括pareq消息和支付授权请求消息。
74.在步骤602，目录服务器(106)将交易消息发送到发行方系统(107)的acs(203)以用于认证和授权，这取决于pareq消息和支付授权消息的存在。在一些非限制性实施例或方面，目录服务器(106)能够从交易消息检取m-otp和时间数据，并将m-otp和时间数据提供到acs(203)以用于认证。在认证成功后，目录服务器(106)可以将包括交易详情的交易消息发送到acs(203)以用于授权。在一些非限制性实施例或方面，目录服务器(106)可以将交易消息发送到acs(203)，而无需检取m-otp。acs(203)可以检取m-otp，认证和授权交易。在认证和授权后，acs(203)生成如图5的步骤(503)中所解释的pares消息，并将pares消息提供到目录服务器(106)。
75.在一些非限制性实施例或方面，为了确保无缝认证，目录服务器(106)可以认证交易。为了使目录服务器(106)进行认证，持卡人的装置(103)应配置有能够生成m-otp的互操作性域移动应用程序。在认证m-otp之后，目录服务器(106)可以将交易消息发送到acs(203)以用于授权。
76.在步骤603，目录服务器(106)从acs(203)接收pares消息。在一些非限制性实施例或方面，目录服务器(106)将pares结果存放在本地分类账中。在本地分类账中存放pares结果可用于确定基于m-otp的交易消息的成功率。
77.在步骤604，目录服务器(106)经由收单方系统(105)将pares消息提供到商家系统(104)。商家系统(104)可以在商家结账页面上将pares消息的结果提供给持卡人(101)。
78.图8a示出根据本公开的一些非限制性实施例或方面的在支付交易期间不通过3d轨道发送的基于m-otp的消息的流。如图所示，商家系统(104)生成包括m-otp的交易消息。商家系统(104)进一步将pareq消息包括在交易消息中并将包括pareq消息的交易消息发送到收单方系统(105)。收单方系统(105)接收包括m-otp和pareq消息的交易消息并在交易消息中附加支付授权请求消息。此外，收单方系统(105)将包括pareq消息和支付授权请求消息的交易消息发送到目录服务器(106)。目录服务器(106)将包括pareq消息和支付授权请求消息的交易消息路由到发行方系统(107)。
79.在一些非限制性实施例或方面，发行方系统(107)认证交易消息并基于认证的结果授权所述交易消息。基于授权的结果，发行方系统(107)生成包括认证和授权的结果的pares消息。将pares消息提供到目录服务器(106)，所述目录服务器继而将pares消息路由到收单方系统(105)。此外，收单方系统(105)将pares消息发送到商家系统(104)，所述商家系统基于pares消息中所附的认证和授权的结果而在商家结账页面上显示适当消息。
80.在一些非限制性实施例或方面，这种基于m-otb的交易技术减少平台(100)中的一个消息。因此，减少额外消息的处理以及减少时间。对于所有实体(商家系统(104)、收单方系统(105)、目录服务器(106)和发行方系统(107))，管理交易的复杂性降低。
81.图8b示出根据本公开的一些非限制性实施例或方面的在支付交易期间通过3d轨道发送的基于m-otp的消息的流。如图所示，商家系统(104)生成包括m-otp的交易消息。商家系统(104)进一步将pareq消息包括在交易消息中并将包括pareq消息的交易消息发送到收单方系统(105)。收单方系统(105)接收包括m-otp和pareq消息的交易消息。此外，收单方系统(105)将包括pareq消息的交易消息发送到目录服务器(106)。目录服务器(106)将包括pareq消息的交易消息路由到发行方系统(107)。
82.在一些非限制性实施例或方面，发行方系统(107)认证交易消息。基于认证的结
果，发行方系统(107)生成指示认证的结果的密码。在一些非限制性实施例或方面，发行方系统(107)保留交易消息。将密码消息提供到目录服务器(106)，所述目录服务器继而经由收单方系统(105)将密码路由到商家系统(104)。如果认证不成功，则商家系统(104)在商家结账页面上显示适当消息。如果认证成功，则商家系统(104)生成支付授权请求消息。此外，将支付授权请求消息连同密码一起提供到收单方系统(105)。收单方系统(105)经由目录服务器(106)将支付授权请求消息连同密码一起路由到发行方系统(107)。发行方系统(107)在接收到支付授权请求消息连同密码后基于由发行方系统(107)保留的交易详情来授权交易。此外，发行方系统(107)生成包括授权的结果的支付授权响应消息。支付授权请求消息经由目录服务器(106)和收单方系统(105)传送到商家系统(104)。然后，商家系统(104)基于授权的结果在商家结账页面上显示适当消息。
83.在一些非限制性实施例或方面，基于m-otp的交易增加了安全性，因为otp不通过电信网络共享给持卡人(101)。此外，由于m-otp不依赖于电信网络，因此由电信网络中的故障引起的故障不会影响交易。此外，完成交易的时间减少，因为m-otp可以由持卡人(101)生成，而不是由发行方系统(107)提供。
84.图9示出用于实施与本公开一致的实施例的示例性计算机系统(900)的框图。在一些非限制性实施例或方面，计算机系统(900)用于实施用于在平台(100)中授权交易的方法。计算机系统(900)可包括中央处理单元(“cpu”或“处理器”)(902)。处理器(902)可包括用于在运行时间执行用于动态资源分配的程序组件的至少一个数据处理器。处理器(902)可包括专用处理单元，例如集成系统(总线)控制器、存储器管理控制单元、浮点单元、图形处理单元、数字信号处理单元等。
85.处理器(902)可安置成经由输入/输出(i/o)接口(901)与一个或多个i/o装置(未示出)通信。i/o接口(901)可以采用通信协议/方法，例如但不限于音频、模拟、数字、单声道、rca、立体声、ieee-1394、串行总线、通用串行总线(usb)、红外线、ps/2、bnc、同轴、组件、复合、数字视频接口(dvi)、高清多媒体接口(hdmi)、rf天线、s-video、vga、ieee 802.n/b/g/n/x、蓝牙、蜂窝(例如，码分多址(cdma)、高速分组接入(hspa )、全球移动通信系统(gsm)、长期演进(lte)、)等。
86.使用i/o接口(901)，计算机系统(900)可以与一个或多个i/o装置通信。例如，输入装置(910)可以是天线、键盘、鼠标、操纵杆、(红外线)远程控制、相机、读卡器、传真机、加密狗(dongle)、生物特征读取器、麦克风、触摸屏、触摸垫、轨迹球、触控笔、扫描器、存储装置、收发器、视频装置/源等。输出装置(911)可以是打印机、传真机、视频显示器(例如，阴极射线管(crt)、液晶显示器(lcd)、发光二极管(led)、等离子体、等离子体显示面板(pdp)、有机发光二极管显示器(oled)等)、音频扬声器等。
87.在一些实施例中，计算机系统(900)通过通信网络(909)连接到服务运营商。处理器(902)可以安置成经由网络接口(903)与通信网络(909)通信。网络接口(903)可以与通信网络(909)通信。网络接口(903)可以采用连接协议，包括但不限于直接连接、以太网(例如，双绞线10/100/1000base t)、传输控制协议/因特网协议(tcp/ip)、令牌环、ieee 802.11a/b/g/n/x等。通信网络(909)可以包括但不限于直接互连、电子商务网络、对等(p2p)网络、局域网(lan)、广域网(wan)、无线网络(例如，使用无线应用协议)、因特网、wi-fi等。使用网络接口(903)和通信网络(909)，计算机系统(900)可以与一个或多个服务运营商通信。
88.在一些实施例中，处理器(902)可以安置成经由存储接口(904)与存储器(905)(例如，图9中未示出的ram、rom等)通信。存储接口(904)可以连接到存储器(905)，包括但不限于存储器驱动器、可移动光盘驱动器等，所述存储器采用连接协议，例如串行高级技术附件(sata)、电子集成驱动器(ide)、ieee-1394、通用串行总线(usb)、光纤通道、小型计算机系统接口(scsi)等。存储器驱动器还可包括鼓(drum)、磁盘驱动器、磁光盘驱动器、光盘驱动器、独立光盘冗余阵列(raid)、固态存储器装置、固态驱动器等。
89.存储器(905)可以存储程序或数据库组件的集合，包括但不限于用户界面(906)、操作系统(907)、网络服务器(908)等。在一些实施例中，计算机系统(900)可以存储用户/应用程序数据，例如本公开所描述的数据、变量、记录等。此类数据库可以实施为容错的、关系的、可扩展的、安全的数据库，例如oracle或sybase。
90.操作系统(907)可以促进计算机系统(900)的资源管理和操作。操作系统的实例包括但不限于apple macintosh os x、unix、unix类系统分布(例如，berkeley软件分布(bsd)、freebsd、netbsd、openbsd等)、linux分布(例如，red hat、ubuntu、kubuntu等)、ibm os、ios/2、microsoft windows(xp、vista/7/8、10等)、apple ios、google android、blackberry os等。
91.在一些实施例中，计算机系统(900)可以实施网页浏览器(908)存储程序组件。网页浏览器(908)可以是超文本查看应用程序，例如microsoft因特网浏览器、google chrome、mozilla firefox、apple safari等。可以使用超文本安全传输协议(https)、安全套接字层(ssl)、传输层安全(tls)等来提供安全网络浏览。网页浏览器(908)可以利用例如ajax、dhtml、adobe flash、javascript、java、应用程序编程接口(api)等设施。在一些实施例中，计算机系统(900)可以实施邮件服务器存储程序组件。邮件服务器可以是因特网邮件服务器，例如microsoft exchange等。邮件服务器可以利用例如asp、activex、ansi c /c#、microsoft.net、cgi脚本、java、javascript、perl、php、python、webobjects等的设施。邮件服务器可以利用例如因特网消息访问协议(imap)、消息应用程序编程接口(mapi)、microsoft exchange、邮局协议(pop)、简单邮件传输协议(smtp)等通信协议。在一些实施例中，计算机系统(900)可以实施邮件客户端存储程序组件。邮件客户端可以是邮件查看应用程序，例如apple mail、microsoft entourage、microsoft outlook、mozilla thunderbird等。
92.在一些非限制性实施例或方面，计算机系统(900)是目录服务器，其提供用于促进与收单方系统相关联的商家与发行方系统之间的交易的服务。在一些非限制性实施例或方面，计算机系统(900)连接到包括商家、收单方系统和发行方系统的实体。
93.除非另外明确指定，否则术语“实施例”、“一个或多个实施例”、“一些实施例”、“一些非限制性实施例或方面”和“一个实施例”意指“本公开的一个或多个(但非所有)实施例”。
94.除非另外明确指定，否则术语“包括(including/comprising)”、“具有”以及其变体意指“包括但不限于”。
95.除非另外明确指定，否则列举的项目列表并不意味着任何或所有项目是相互排斥的。除非另外明确指定，否则术语“一个(a/an)”和“所述”意指“一个或多个”。
96.具有彼此通信的数个组件的实施例的描述并不意味着所有这些组件都是需要的。
相反，描述了各种可选组件以示出本公开的各种可能的非限制性实施例或方面。
97.当本文中描述单个装置或物品时，将显而易见的是，可以使用多于一个装置/物品(无论其是否协作)来代替单个装置/物品。类似地，在本文中描述多于一个装置或物品的情况下(无论其是否协作)，将容易显而易见的是，可以使用单个装置/物品来代替多于一个装置或物品，或者可以使用不同数量的装置/物品来代替所示数量的装置或程序。装置的功能性和/或特征可以替代地由未明确描述为具有此类功能性/特征的一个或多个其它装置体现。因此，本公开的其它实施例或方面无需包括装置本身。
98.图5、图6的所示操作示出以某一次序发生的某些事件。在替代实施例中，可以按不同次序执行、修改或去除某些操作。此外，可以向上文所描述的逻辑添加步骤，并且所述步骤仍符合所描述的实施例。此外，本文所述的操作可以按顺序进行，或某些操作可以并行处理。然而，操作可以由单个处理单元或分布式处理单元执行。
99.最后，说明书中使用的语言主要是出于可读性和教导目的而选择的，不是为了划定或限制发明主题而选择的。因此希望本公开的范围不受此具体实施方式的限制，而是受关于基于本公开的应用所发出的任何权利要求的限制。因此，本公开的实施例或方面的公开内容旨在是说明性的，而不是限制在所附权利要求书中阐述的本公开的范围。
100.虽然本文中已公开了各个方面和实施例，但本领域的技术人员应清楚其它方面和实施例。本文所公开的各个方面和实施例是出于说明的目的并且不旨在是限制性的，其中真实的范围和精神由所附权利要求书指示。