首页 / 与卡发行商的卡处理系统的数字卡集成

与卡发行商的卡处理系统的数字卡集成实质审查 发明

技术内容

与卡发行商的卡处理系统的数字卡集成 相关申请的交叉引用 [0001] 本申请作为PCT国际专利申请于2023年1月27日递交,并且要求于2022年1月27日递交的美国专利申请序列号63/303,780的权益和优先权,其公开内容通过引用整体并入本文。 背景技术 [0002] 通过卡网络引入的通证化系统已经使数字卡成为可能。示例包括万事达 (Mastercard)MDES、Visa VTS和银行卡CB数字中心(Cartes Bancaires CB Digital Hub)。 这些通证化系统已经允许银行能够将其卡组合数字化,用专用于特定用例的通证替换敏感的卡号,以增强安全性。同时,消费者和卡发行商越来越多地从实体卡转向完全数字的卡。 [0003] 该向数字卡系统的转变已经带来了重大挑战。例如,由于不同的卡发行商、地方政府和标准机构通常已经采用不同的通证化方案,因此金融机构面临着与多个通证化系统的集成。为了实现这些创新,发行商通常依赖若干个卡系统,从而导致极大的复杂性、多个后端卡发行商集成、以及漫长的开发时间线。 [0004] 此外,数字卡通常需要与移动银行应用的紧密集成。由于卡注册、支付、余额查询、卡管理和认证流程通常都可以在移动银行应用中进行,因此银行机构需要提供与这些应用集成的数字卡,以向客户提供统一的服务。 [0005] 当向客户提供数字卡(包括在移动银行应用中)时,通常使某些功能可用于客户,包括显示卡号信息和PIN信息(被统称为“卡信息”)。然而,由于该卡信息很敏感,因此需要一种提供高度安全性(例如,符合PCI‑DSS)的技术解决方案,这限制了许多现有系统的灵活性。 发明内容 [0006] 一般而言,本申请涉及用于管理数字钱包的方法和系统,包括支付卡的注册和这些支付卡的使用。数字钱包可以被集成到由卡发行商提供的移动应用中,其中数字钱包提供移动应用和支付服务提供商之间的集成,该支付服务提供商提供用于实现虚拟卡的基于通证的支付系统。 [0007] 在第一方面,提供了一种将数字支付卡与卡发行商移动应用进行集成的方法。该方法包括:在卡发行商处从移动应用接收标识支付卡的卡标识符;以及从卡发行商向钱包服务器发送卡标识信息,该卡标识信息包括卡标识符以及与支付卡相关联的持卡人的标识符。该方法还包括:在卡发行商处从钱包服务器接收卡推送数据;以及向移动应用提供卡推送数据。移动应用经由与钱包服务器相关联的软件开发套件(SDK)向钱包服务器提供卡注册推送数据。 [0008] 在第二方面,提供了一种将数字支付卡与卡发行商移动应用进行集成的方法。该方法包括:在钱包服务器处从卡发行商接收卡标识信息,该卡标识信息包括标识支付卡的卡标识符以及与支付卡相关联的持卡人的标识符。该方法还包括从钱包服务器向卡发行商发送卡推送数据。该方法还包括:从其上安装有移动应用的移动设备接收表示资金卡推送数据的第一信息,该移动应用经由安装在移动设备上的软件包与钱包服务器对接,并且被配置为直接与钱包服务器通信,资金卡推送数据包括与移动设备相关联的标识符。 [0009] 在第三方面,一种方法包括:在钱包服务器处接收对基于通证的支付特征的请求,该请求是直接从软件开发套件(SDK)接收的,该SDK安装在移动设备处并且与卡发行商所关联的移动应用进行集成,该SDK由控制钱包服务器的实体提供。该方法包括:从钱包服务器向通证服务提供商提交用于使用基于通证的支付特征的卡和交易信息;以及在钱包服务器处接收来自通证服务提供商的响应,该响应指示提交卡和交易信息的结果。该方法还包括: 经由SDK将该结果转发给移动设备,该结果被提供给由卡发行商提供的移动应用。 附图说明 [0010] 图1示出了可以实现本公开的各方面的示例环境。 [0011] 图2A示出了根据本公开的各方面的从链接到钱包服务器的卡发行商的角度在移动钱包中注册卡数据的示例方法。 [0012] 图2B示出了根据本公开的各方面的从钱包服务器的角度在移动钱包中注册卡数据的示例方法。 [0013] 图3示出了使用数字钱包内的已注册资金卡的示例方法,该已注册资金卡是根据上面结合图2A至图2B描述的方法而注册的。 [0014] 图4示出了根据示例实施例的移动设备、卡发行商和钱包服务器之间的用于在数字钱包内注册卡的示例消息流。 [0015] 图5示出了移动设备、卡发行商、钱包服务器和通证服务提供商之间的用于使用数字钱包内的卡进行支付交易的示例消息流。 [0016] 图6示出了可以实现本公开的各方面的示例计算设备。 具体实施方式 [0017] 如上面简要描述的,本发明的实施例涉及用于管理数字钱包的方法和系统,包括支付卡的注册和这些支付卡的使用。数字钱包可以被集成到由卡发行商提供的移动应用中,其中数字钱包提供移动应用和支付服务提供商之间的集成,该支付服务提供商提供用于实现虚拟卡的基于通证的支付系统。 [0018] 一般而言,本文所述的数字钱包提供了一种将由卡发行商(例如,银行或其他金融机构)提供的移动应用与通证服务提供商(诸如万事达MDES、Visa VTS、以及银行卡CB数字中心或利用基于通证的交易的其他类似提供商)进行集成的便捷方法。数字钱包可以维护足够的数据来表示虚拟卡,并且这种操作可以在钱包服务器处的集中位置进行,或分布在钱包服务器和安全移动软件开发套件(SDK)之间,该安全移动SDK可以与由卡发行商提供的移动应用进行集成。因此,卡发行商不需要开发其自己的与通证服务提供商的接口,而是可以依靠数字钱包和钱包服务器来提供与各种通证服务提供商的接口。因此,从卡发行商的角度来看,与附加通证服务提供商的集成非常直接,因为该集成由钱包服务器代表卡发行商进行管理。 [0019] 现在参考图1,示出了可以实现本公开的各方面的示例环境100。在示例环境100中,卡发行商14可以向用户10发行支付卡,诸如信用卡12。信用卡12可以是实体信用卡,或者可以仅是虚拟卡。卡发行商14可以是银行或其他金融机构,并且用户10可以在卡发行商处拥有一个或多个账户,包括信用账户或其他类型的银行账户(例如,支票和/或储蓄账户)。 [0020] 为了允许用户10管理他或她的账户,卡发行商14可以向用户10提供可安装在移动设备20上的移动应用18。移动应用18可以被配置为接收用户凭证并允许访问用户10在由卡发行商14表示的金融机构处的账户信息。 [0021] 在示例实现中,用户10可能希望将信用卡12的数字版本存储在他或她的移动设备 20上的移动钱包中。移动钱包可以在移动应用18内实现。在传统实现中,移动应用18可能需要与通证服务提供商50进行集成,例如以交换表示包括卡信息在内的支付细节的通证。然而,在这些配置中,移动应用18将需要定义与通证服务提供商50的接口。 [0022] 在所示的示例中,钱包服务器102可以与卡发行商14、移动设备20和通证服务提供商50中的每一个进行通信。如下面进一步所述,钱包服务器102可以与移动软件开发套件(SDK)104耦合,以提供移动应用18和通证服务提供商50之间的接口并维护例如由卡发行商 14发行的信用卡12的支付卡详细信息。 [0023] 在示例实现中,可以将移动SDK 104直接从钱包服务器102提供给移动设备20,以与移动应用18进行集成。在其他实现中,可以将移动SDK 104提供给卡发行商以与移动应用 18进行集成,该移动应用18进而可被用户10访问并安装在移动设备20上。因此,在安装时,移动设备20将具有移动应用18和移动SDK 104两者,并且将被配置为与卡发行商14和钱包服务器102两者进行通信,使得在用户10希望将支付卡注册在移动设备20上的移动钱包内时,这种移动钱包(其经由移动SDK 104和钱包服务器102来实现)已到位并且准备好使用。 [0024] 在示例实现中,可以将支付卡信息从移动设备20提供给钱包服务器102。一旦钱包服务器102具有支付信息和卡数据,钱包服务器就可以向通证服务提供商50提供支付信息,并且可以代表用户和移动应用18进行操作。如下面进一步详细所述,卡数据可以存储在钱包服务器102处的卡数据库106中,可以经由SDK 104在移动设备20处的存储设备中维护,或者这两者的组合。在示例中,卡信息的密码可以存储在移动设备20和钱包服务器102中的每一个处,以用于在向通证服务提供商50提交支付请求之前的重建。因此,在交易时,卡信息可以仅在移动设备20或公共服务器102上维护,而不是将卡信息保留在可能因访问漏洞等而被泄漏的任一位置处。 [0025] 应当注意,在图1中描述的环境100的上下文下,钱包服务器102和SDK 104的使用允许移动设备20和钱包服务器102之间的紧密耦合。具体地,对于虚拟卡在数字钱包内的初始注册,移动设备可以使用SDK 104来直接与钱包服务器102进行通信,而不需要与可能由卡发行商14托管或管理的移动应用服务器进行中间通信。这减少了所需的实体间通信量,从而进一步提高效率并增强安全性。 [0026] 现在参考图2A,示出了根据本公开的方面的在移动钱包中注册卡数据的示例方法 200。方法200被描述为结合从链接到钱包服务器的卡发行商的角度执行的操作,如上文结合图1所述。 [0027] 在所示的示例中,方法200包括在卡发行商(诸如卡发行商14)处接收卡标识符(步骤202)。例如可以从用户(诸如用户10)的移动应用接收卡标识符,并且该卡标识符可以标识要添加到数字钱包的支付卡。卡标识符可以包括卡详细信息,诸如卡号、失效日期和验证码。 [0028] 如图所示,方法200还包括从卡发行商14向钱包服务器102发送注册数据(步骤 204)。注册数据例如可以包括:从移动应用接收到的卡标识符,以及用户的标识符或该卡应添加到的数字钱包的标识符。备选地,不是仅发送卡标识符以及用户或数字钱包的标识符,而是可以将卡数据从发行商14发送给钱包服务器102。卡数据可以包括主账号(PAN)和失效日期,并且可选地包括用于保护这种数据的密文(cryptogram)。 [0029] 在所示的示例中,方法200还包括在卡发行商14处从钱包服务器102接收资金卡推送数据(步骤206)。卡发行商进而将向移动应用提供推送数据(步骤208)。响应于向移动应用18提供推送数据,移动设备可以被配置为例如经由SDK 104将该推送数据从移动应用提供给钱包服务器102(步骤210)。 [0030] 图2B示出了根据本公开的各方面的从钱包服务器的角度在移动钱包中注册卡数据的示例方法220。换言之,方法220类似于方法200,但从钱包服务器102的角度来看,而不是从卡发行商14的角度来看。 [0031] 在所示的示例中,方法220包括在钱包服务器102处收接注册数据(步骤222)。如上面在方法200的步骤204中所述,注册数据将包括用户标识符或钱包标识符以及一些卡标识信息。卡标识信息可以包括卡标识符,或者可以是主帐号和失效日期,以及用于保护该数据的可选密文。 [0032] 在所示的示例中,方法220还包括向卡发行商14发送资金卡推送数据(步骤224)。 该方法还包括在钱包服务器102处从移动设备接收卡注册信息(步骤226)。在示例中,资金卡推送数据格式可以至少部分地取决于给定支付卡的通证服务提供商。资金卡推送数据例如可以包括将支付卡纳入数字钱包所需的各种有效载荷和密文。 [0033] 尽管资金卡推送数据的确切构造可因不同的通证服务提供商而变化,但应当注意,钱包服务器102代表卡发行商维护资金卡推送数据的定义并能够形成资金卡推送数据,使得钱包服务器102可以向卡发行商转发推送数据,该卡发行商进而可以将该推送数据提供给移动设备20处的移动应用18。然后,移动应用18可以通过例如经由SDK 104向钱包服务器102发送确认注册的消息来完成注册(在步骤226处)。以这种方式,钱包服务器102接收对向卡发行商提供的资金卡推送数据被成功地提供给移动应用的确认,并且确认卡发行商 14、用户10的移动设备20、以及在钱包服务器102处注册的特定用户或钱包之间的关联。 [0034] 现在参考图3,示出了使用数字钱包内的已注册资金卡的示例方法300,该已注册资金卡是根据上面结合图2A至图2B描述的方法而注册的。例如,可以使用其中安装有SDK的移动应用,与可用于与通证服务提供商对接的钱包服务器相关联地执行方法300,如上所述。 [0035] 在所示的示例中,方法300包括例如通过接收某种类型的用户认证信息并将该信息与存储的凭证进行验证,来认证用户(步骤302)。认证用户例如可以包括:接收并比较pin码,接收指纹并将其与存储的已知指纹进行比较,或者任何其他类型的已知认证过程。在示例实现中,方法300使用现有移动设备认证过程来在移动应用18内认证用户。 [0036] 方法300还包括接收特征请求(步骤304)。在示例中,该特征请求可以是使用通证服务提供商进行支付的请求。然而,也可以利用其他类型的请求。例如,请求与通证服务提供商相关联的支付卡的卡详细信息,或者请求以其他方式使用通证服务提供商发起交易。 在示例中,在移动设备20处例如经由用户输入或经由与移动设备的无线通信(例如,经由近场通信(NFC))接收特征请求。然后,可以将特征请求转发给钱包服务器,以根据与先前在用户的数字钱包中注册的支付卡相关联的具体通证服务提供商来进行处理。 [0037] 一旦钱包服务器已经接收到特征请求,钱包服务器102然后就可以确定它是否已经存储发起与通证服务提供商50的交易所需的相关卡数据(步骤306)。例如,钱包服务器 102可以仅存储卡信息的进行交易所需的部分,诸如卡信息的密码。在这种情况下,例如通过取回可以与钱包服务器处存储的信息结合使用以重建卡信息的其他解密信息,钱包服务器可以取回所需的任何其他信息(步骤308)。在示例实施例中,可以使用密码对卡信息执行异或运算,其中,密码存储在用户的移动设备20上的SDK 104处,并且经解密的信息存储在钱包服务器102处的卡数据106中。也可以使用相反的存储配置。 [0038] 如果钱包服务器102例如在数据库106处或者在重建卡信息之后存储了整个卡信息,则钱包服务器可以确定在钱包服务器处是否在用户的钱包中存储了完整的卡信息(步骤310)。完整的卡信息通常对应于进行金融交易所需的信息。即,上面在步骤306至308中描述的卡信息可以是卡号、账号和失效日期、以及用于进行金融交易的必要信息,或者备选地,可以仅是卡标识符。如果钱包服务器仅存储卡标识符(例如,出于安全目的),则钱包服务器102可以向卡发行商14发送请求以获得进行金融交易所需的卡信息(步骤312)。 [0039] 一旦钱包服务器102接收到完整的卡信息(例如,来自卡数据库106、基于根据密码的重建、或从卡发行商14获得),钱包服务器102就可以向通证服务提供商50提交动作(步骤 314)。然后,通证服务提供商50可以返回交易的结果(例如,成功或失败),并且钱包服务器 102将例如经由SDK 104向移动设备20处的移动应用18提供类似的结果(步骤316)。因此,移动设备20的用户10将接收关于要经由通证服务提供商50执行的交易的成功或失败的立即反馈。 [0040] 现在参考图4至图5,示出了移动设备(例如,前述安装有移动应用18和SDK 104的移动设备20)、钱包服务器102、通证服务提供商50和卡发行商14之间的一组总体消息流。具体地,图4示出了用于在数字钱包内注册卡的第一示例消息流400,并且图5示出了用于使用数字钱包内的卡进行交易的示例消息流500。 [0041] 首先参考图4,在移动应用20处发起消息流400,该移动应用20向卡发行商14提交注册卡的请求。注册卡的请求可以包括卡标识符(例如,卡发行商已知的特定卡标识符)或新卡信息,该新卡信息包括卡号和失效日期、账号、或其他类型的卡或账户详细信息。一旦接收到该请求并且将其验证为来自已知用户,卡发行商14就向钱包服务器102发送注册数据。钱包服务器将生成资金卡推送数据,并且将该资金卡推送数据发送回卡发行商14。 [0042] 在示例实施例中,从卡发行商14发送给钱包服务器102的注册数据例如可以包括卡标识信息(诸如卡标识符或特定卡详细信息)以及与该用户相关联的钱包标识符或客户端标识符,以确保与适当的用户相关联地存储该卡详细信息。资金卡推送数据例如可以包括通证服务提供商所需的特定资金卡通证或密文,并且该资金卡推送数据是根据要使用的目标通证服务提供商而在钱包服务器102处生成的。因此,卡发行商14不需要知道如何为具体通证服务提供商配置通证,而是可以依赖钱包服务器102来执行这些功能。 [0043] 一旦卡发行商14接收到资金卡推送数据,它就可以将该资金卡推送数据提供给移动设备20处的移动应用18。然后,移动应用18可以通过向与钱包服务器102相关联的SDK  104发送资金卡推送数据来确认注册。SDK 104可以将资金卡推送数据提供回钱包服务器,从而验证卡发行商14和移动应用18已经成功地接收到该信息。然后,钱包服务器102可以与通证服务提供商相关联地注册移动应用,并且将该相互关系存储在由钱包标识符或用户标识符标识的数字钱包中。 [0044] 在示例实施例中,钱包服务器102可以不保留所有注册数据,即所有卡标识信息。 例如,对于钱包服务器102而言,为了避免在数据泄露事件中危及卡信息,维护卡或支付账户信息可能是不利的。因此,在一些实施例中,钱包服务器可以对卡数据执行加密,诸如异或运算。密码信息或被加密的结果可以返回到SDK 104以存储在移动设备20上。此后,仅密码和被加密信息的组合可被用于重新创建卡信息,因此,如果数据遭受危险,则仅钱包服务器处(或仅移动设备20处)的数据不足以泄露卡信息。 [0045] 参考图5,示出了根据示例实施例的消息流500,消息流500描绘了经由通证服务提供商50且使用由钱包服务器102维护的数字钱包的对支付卡的基于通证的特征的使用。在所示的示例中,用户可以例如经由移动设备20上的移动应用18请求支付卡的特征。移动应用18将向SDK 104提交该请求,该SDK 104然后请求对用户10的认证。例如,可以使用由SDK和钱包服务器102实现的特定认证方法(例如,使用多因素认证、生物特征认证或其他手段)来执行认证,或者认证可以依赖于由移动设备操作系统在移动设备本地提供的认证方法,诸如Apple FaceID、或在AppleOS或Android移动操作系统中实现的PIN码或指纹。 [0046] 在钱包服务器102处,获得卡信息,以最终提交给通证服务提供商50。在一个实施例中,钱包服务器102可以存储与通证服务提供商50进行通信以请求要执行的动作(例如,支付)所需的所有相关通证信息或支付卡信息。在这种情况下,钱包服务器102可以简单地向通证服务提供商提交要执行的动作,并且响应于此来接收结果。然而,在其他实施例中,钱包服务器102可以仅维护卡信息的一部分。这可能是因为钱包服务器102仅维护卡信息的密码或加密版本(在本文中也被称为可用于重建卡信息的“第一信息”的示例),而其余部分(在本文中被称为“第二信息”的示例)在SDK 104中维护。这也可能是因为钱包服务器102仅保留卡标识符,而卡详细信息仅由卡发行商14来维护。 [0047] 如果钱包服务器102仅维护卡信息的密码或加密版本,则钱包服务器102可以向SDK 104请求剩余卡信息重建数据,并且在向通证服务提供商50提交对动作的请求之前重建卡信息。如果例如钱包服务器仅维护卡标识符(或仅根据密码来重建卡标识符,如上所述),则钱包服务器可以在向通证服务提供商50提交请求之前向卡发行商提交卡标识符。卡发行商14可以返回主账号、失效日期、以及可选地用于保护使用卡信息的交易的密文和/或PIN。无论钱包服务器102如何接收卡信息,最终它都将向通证服务提供商50提交对动作或信息的请求,接收结果,并且经由SDK 104将该结果传递回移动应用18。 [0048] 应当注意,在图4至图5中,与通证服务提供商50的通信由钱包服务器102来居间,因为卡发行商14和移动设备20不需要直接与通证服务提供商进行通信。因此,如果不同的卡使用不同的通证服务提供商,或者如果由通证服务提供商公开的API可能随时间而改变,则为了集成或更改该提供商提供的特征,可以更新钱包服务器,而无需通知移动设备20处的移动应用18或通知卡发行商14。又此外,钱包服务器102和卡发行商14之间的通信可以通过由卡发行商公开的API。 [0049] 通过使用SDK 104和钱包服务器102之间的紧密耦合,本解决方案避免了移动应用必须经由卡发行商的移动应用服务器或其他计算系统将数据中继到钱包服务器的需求。另外,钱包服务器102可以经由SDK 104直接与移动应用18通信,且与卡发行商14和通证服务提供商50通信,从而提高支付网络内的整体通信效率,这具有提高安全性的附加益处。 [0050] 图6示出了可以实现本公开的各方面的示例计算设备600。计算设备600例如可以用作单个设备或联网设备组以实现如上所述的移动设备20、钱包服务器102、通证服务提供商50或卡发行商14。 [0051] 在图6的示例中,计算设备600包括存储器602、处理系统604、辅助存储设备606、网络接口卡608、视频接口610、显示单元612、外部组件接口614和通信介质616。存储器602包括能够存储数据和/或指令的一个或多个计算机存储介质。在不同的实施例中,存储器602以不同的方式实现。例如,存储器602可以使用各种类型的计算机存储介质来实现,并且通常包括至少一些有形介质。在一些实施例中,存储器602使用完全非暂时性介质来实现。 [0052] 处理系统604包括一个或多个处理单元或可编程电路。处理单元是包括选择性地执行软件指令的一个或多个集成电路的物理设备或制品。在各种实施例中,处理系统604以各种方式实现。例如,处理系统604可以被实现为一个或多个物理或逻辑处理核心。在另一示例中,处理系统604可以包括一个或多个单独的微处理器。在另一示例实施例中,处理系统604可以包括提供特定功能的专用集成电路(ASIC)。在另一示例中,处理系统604通过使用ASIC并执行计算机可执行指令来提供特定功能。 [0053] 辅助存储设备606包括一个或多个计算机存储介质。辅助存储设备606存储不能由处理系统604直接访问的数据和软件指令。换言之,处理系统604执行I/O操作以从辅助存储设备606取回数据和/或软件指令。在各种实施例中,辅助存储设备606包括各种类型的计算机存储介质。例如,辅助存储设备606可以包括一个或多个磁盘、磁带驱动器、光盘、固态存储器设备和/或其他类型的有形计算机存储介质。 [0054] 网络接口卡608使得计算设备600能够向通信网络发送数据以及从通信网络接收数据。在不同的实施例中,网络接口卡608以不同的方式实现。例如,网络接口卡608可以被实现为以太网接口、令牌环网络接口、光纤网络接口、无线网络接口(例如,WiFi、WiMax等)或其他类型的网络接口。 [0055] 在计算设备600包括视频接口610的可选实施例中,视频接口610使得计算设备600能够向显示单元612输出视频信息。显示单元612可以是用于显示视频信息的各种类型的设备,诸如LCD显示面板、等离子屏幕显示面板、触敏显示面板、LED屏幕、阴极射线管显示器或投影仪。视频接口610可以通过多种方式与显示单元612进行通信,诸如经由通用串行总线(USB)连接器、VGA连接器、数字视频接口(DVI)连接器、S视频连接器、高清多媒体接口(HDMI)接口、或显示端口(DisplayPort)连接器。 [0056] 外部组件接口614使得计算设备600能够与外部设备进行通信。例如,外部组件接口614可以是USB接口、火线(FireWire)接口、串行端口接口、并行端口接口、PS/2接口、和/或使得计算设备600能够与外部设备进行通信的其他类型的接口。在各种实施例中,外部组件接口614使得计算设备600能够与各种外部组件(诸如外部存储设备、输入设备、扬声器、调制解调器、媒体播放器基座、其他计算设备、扫描仪、数码相机和指纹读取器)进行通信。 [0057] 通信介质616促进计算设备600的硬件组件之间的通信。通信介质616促进存储器 602、处理系统604、辅助存储设备606、网络接口卡608、视频接口610和外部组件接口614之间的通信。通信介质616可以以多种方式实现。例如,通信介质616可以包括PCI总线、PCI高速总线、加速图形端口(AGP)总线、串行高级技术附件(ATA)互连、并行ATA互连、光纤通道互连、USB总线、小型计算系统接口(SCSI)接口、或另一类型的通信介质。 [0058] 存储器602存储各种类型的数据和/或软件指令。存储器602存储基本输入/输出系统(BIOS)618和操作系统620。BIOS 618包括计算机可执行指令集,该计算机可执行指令集当由处理系统604执行时,使计算设备600启动。操作系统620包括计算机可执行指令集,该计算机可执行指令集当由处理系统604执行时,使计算设备600提供协调计算设备600的活动和资源共享的操作系统。此外,存储器602存储应用软件622。应用软件622包括计算机可执行指令,该计算机可执行指令当由处理系统604执行时,使计算设备600提供一个或多个应用。在移动设备(诸如移动设备20)的上下文下,应用软件622可以包括能够安装在其上的一个或多个移动应用。存储器602还存储程序数据624。程序数据624是在计算设备600上执行的由程序使用的数据。 [0059] 尽管本文讨论了电子计算设备600内包括的特定特征,但应当认识到,在某些实施例中,并非所有这些组件或特征都可以被包括在根据本公开的方法和系统执行的计算设备内。此外,不同类型的硬件和/或软件系统可以被并入这种电子计算设备中。 [0060] 根据本公开,本文所使用的术语“计算机可读介质”可以包括计算机存储介质和通信介质。如本文档所使用的,计算机存储介质是存储数据和/或计算机可执行指令的设备或制品。计算机存储介质可以包括以任何方法或技术实现的用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的易失性和非易失性、可拆卸和不可拆卸设备或制品。作为示例而非限制,计算机存储介质可以包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM)、低时延DRAM、DDR2 SDRAM、DDR3 SDRAM、固态存储器、只读存储器(ROM)、电可擦除可编程ROM、光盘(例如,CD‑ROM、DVD等)、磁盘(例如,硬盘、软盘等)、磁带、以及存储数据的其他类型的设备和/或制品。通信介质可以以调制数据信号(诸如载波或其他传输机制)体现计算机可读指令、数据结构、程序模块或其他数据,并且包括任何信息传送介质。术语“调制数据信号”可以描述以对信号中的信息进行编码的方式设置或改变的信号,该信号具有一个或多个特征。作为示例而非限制,通信介质可以包括诸如有线网络或直接有线连接的有线介质、以及诸如声学、射频(RF)、红外无线介质、以及其他无线介质。 [0061] 应当注意,在图6的计算设备600的一些实施例中,计算机可读指令存储在包括非暂时性介质在内的设备上。在特定实施例中,计算机可读指令存储在完全非临时介质上[0062] 参考图1至图6,应当注意,上述配置在便利性和安全性两者方面具有多个优点。具体到便利性方面,上述配置允许卡发行商与各种通证服务提供商中的任一通证服务提供商进行集成,而无需在移动应用开发方面付出大量附加努力。此外,从用户10的角度来看,与具体通证服务提供商的集成是无缝的,并且用于与不同通证服务提供商进行集成的过程本质上是相同的。关于安全性,在示例实现中,由卡发行商提供的移动应用不需要保留支付卡详细信息;而是这些详细信息由卡发行商保留,并且可选地由钱包服务器保留。又此外,为了增强安全性,甚至可以将钱包服务器配置为:通过使用加密密码来在移动SDK 104和钱包服务器102之间分割支付卡详细信息,仅保留支付卡详细信息的一部分。因此,在除了当正在发生支付交易时之外的时间期间,移动SDK 104和钱包服务器102都不保留完整的支付卡详细信息,从而降低了支付卡详细信息遭受危险的可能性。 [0063] 尽管已经参考特定装置、材料和实施例描述了本公开,但根据前述描述,本领域技术人员可以容易地确定本公开的基本特征,并且在不脱离所附权利要求中阐述的本发明的精神和范围的情况下,可以进行各种改变和修改以适应各种用途和特性。

相关技术
卡集成相关技术
发行商相关技术
尼古拉斯·布鲁利发明人的其他相关专利技术