电子钱包设备、方法及计算机程序产品的制作方法_3

文档序号:8927041阅读:来源:国知局
行机构986批准的购买金额相同的 购买金额)给所述预支付卡"充值"。电子钱包向实体9999提供预支付PAN及金额。预支 付PAN与和电子商务零售商(例如,美国电子商务零售商、美国预支付卡)相同的国家相关 联。在916处,实体9999格式化以预支付卡发行机构596为目的地的支付交易授权请求且 将支付交易授权请求发送到授权网络987。
[0091] 在917处,授权网络987将支付交易授权请求转发到预支付卡发行机构。在918 处,预支付卡发行机构596将对所述授权请求的经批准响应提供到授权网络987。在919 处,授权网络将授权响应转发到实体9999。在920处,实体9999将指示充值被批准的响应 提供到电子钱包。流程921及922展示钱包与预支付卡发行机构之间的CVC 2请求及响应。 在此方面中,在购买时,在已从资金卡发行机构获得批准且已成功实现充值之后,为使购买 成功,有必要向商家提供使授权通过所需的所有细节。因此,所述商家将需要CVC 2数据。 CVC 2数据通常由商家请求以确保进行在线交易的人真的持有所述卡。在一或多个实施例 中,CVC 2数据未被存储且因此必须从预支付卡发行机构获得。在921及922处,针对特定 预支付卡获得CVC 2值以在购买交易中使用。在923处,由所述钱包向电子商务零售商提 供包含预支付卡PAN、截止日期及CVC 2(如果需要)的支付信息。
[0092] 在924处,电子商务零售商895产生到其收单机构990的请求以支取预支付卡执 行电子商务购买。在925处,电子商务零售商收单机构990格式化以预支付卡发行机构为 目的地的购买授权请求且将购买授权请求发送到授权网络。在926处,所述授权网络将购 买授权请求转发到预支付卡发行机构596。在927处,预支付卡发行机构596将对所述授权 请求的响应提供到所述授权网络。在928处,所述授权网络将所述授权响应提供到电子商 务零售商收单机构。在929处,电子商务零售商收单机构990将所述授权响应转发到电子 商务零售商。在930处,电子商务零售商将购买确认提供到消费者598。
[0093] 预期电子商务零售商收单机构框990是在与电子商务零售商相同的司法管辖区 中的银行,以及由可定位在任何司法管辖区中的银行操作或以所述银行的名义操作的服务 器。预期余额查询服务框989是具有适当软件的服务器,其经配置以将余额查询发送到预 支付卡发行机构以确定多少金额留在所述卡上;此服务器可能处于与电子钱包服务器相同 的司法管辖区中,但也可处于其它地方。预期预支付卡发行机构框596是可能但不一定处 于与电子商务零售商相同的司法管辖区中的预支付卡发行机构以及由所述预支付卡发行 机构运行或以所述预支付卡发行机构的名义运行的可定位在任何司法管辖区中的具有合 适软件的服务器。预期资金卡发行机构框986是最可能处于消费者的祖国的银行机构以及 由此银行机构运行或以此银行机构的名义运行的可定位在任何司法管辖区中的具有合适 软件的服务器。授权网络987通常为跨国网络(例如,上文论述的银行网(BANKNET)或维 萨网(VISANET)网络或其它运营商的支付处理网络)。预期资金购买/支付交易收单机构 /处理器框9999是:(i)收单机构,其处置在购物者祖国的卡上的购买以及在电子商务零售 所定位于的司法管辖区中的预支付卡的充值;以及(ii)服务器,其由此收单机构运行或以 此收单机构的名义运行,所述服务器具有合适软件。所述服务器及收单机构可处于任何司 法管辖区中且其本身可处于相同或不同司法管辖区中。在一些情形中,框9999的功能性可 在两个或多于两个不同实体之间划分。
[0094] 应适当考虑可适用的法律及法规注意事项及/或合同义务,这是因为在一些实施 例中,商家将接受在技术上并非消费者的资金卡的卡并配送到并非消费者的实际配送地址 的地址;此外,在一些实施例中,也不存在发行实体卡(预支付或其它)卡的情况(其是虚 拟的)。
[0095] 在涉及此类注意事项的那些实施例中,应适当考虑解决配送商家收单机构及预支 付卡发行机构可能不愿冒险在结算发生之前发送及/或批准交易方面的问题。在一些实施 例中,配送商家将在资金卡购买时在结算已发生之前起始支付交易授权请求,及/或预支 付卡发行机构将在支付交易时在结算已发生之前批准电子商务购买。
[0096] 在一些情形中,预支付卡发行机构将能够将预支付卡上的购买仅限制到那些通过 钱包发生的购买一举例来说,将确保账单及/或配送地址为配送商家的仓库。在其它情形 中,在授权请求中将需要额外指示符来指示所述交易是经由电子钱包产生。其它情形不涉 及单独预支付卡且在此类情形中,这些注意事项不是问题。
[0097]图10描绘使用本地资金卡的国际商家处的示范性交易,其中商家接受外国发行 的卡。在1001处,消费者598对关于是否继续进行结账的查询做出肯定的响应。在1002处, 电子商务零售商895产生到电子钱包的呼叫以检索支付方法及确认配送地址信息。在1003 处,电子钱包597将支付信息提供到电子商务零售商895,所述支付信息包含资金卡PAN及 截止日期。在一或多个实施例中,电子钱包不存储资金卡CVC 2,所以如果电子商务零售商 需要CVC 2,那么消费者将需要在电子商务零售商站点上填充所述字段。在1004处,电子商 务零售商产生到其收单机构990的请求以支取资金卡执行电子商务购买。在1005处,电子 商务零售商收单机构990格式化以资金卡发行机构986为目的地的购买授权请求且将所述 购买授权请求发送到授权网络987。在1006处,授权网络987将购买授权请求转发到资金 卡发行机构986。在1007处,资金卡发行机构将对所述授权请求的经批准响应提供到所述 授权网络。在1008处,所述授权网络将所述授权响应提供到电子商务零售商收单机构990。 在1009处,电子商务零售商收单机构将授权响应转发到电子商务零售商895。在1010处, 电子商务零售商将购买确认提供给所述消费者。在1011处,电子商务零售商产生到清算系 统1081的用于电子商务购买的清算消息(例如,消息类型指示符(MTI) 1240)。在1012处, 所述清算系统将用于电子商务购买的清算消息发送到资金卡发行机构986。预期清算系统 框1081是正常营业清算系统且可定位在(例如)美国或另一司法管辖区中。同样,一些实 施例不涉及跨司法管辖区的方面及/或本地预支付资金卡。
[0098] 本发明的一些实施例涉及数字钱包的虚拟卡号。在本文中使用以下术语:
[0099] 鲁虚拟卡号-在后端与真实卡号(RCN)关联的唯一号码(至少在一些情况下为16 个数字)。所述虚拟卡号可通过若干组规则、警报及限制进行设置,这允许对支付的严格而 灵活的管理
[0100] ?真实卡号(RCN)-写在实体卡上的号码(至少在一些情况下为16个数字)
[0101] ?数字钱包-用户的金融信息(卡号、地址等等)的托管方(host),其促进了仅以 少许点击或交互进行交易
[0102] 鲁卡-信用卡、借记卡或预支付卡
[0103] ?消费者-光顾实体店或在线店的最终用户
[0104] ?商家-在线店或实体店
[0105] ?远程支付-使用任何合适未来装置:桌上型计算机、膝上型计算机、智能电话、 平板计算机及类似者使用因特网连接进行的支付
[0106] ?接近支付-使用近场通信进行的支付
[0107] ?近场通信(NFC)-用于通过使装置触碰在一起或使所述装置极为贴近(通常不 超过几厘米)来使所述装置彼此使用无线电通信的若干组规则(在本文中用于支付用途)
[0108] 信用卡、借记卡及预支付卡包含可用于识别发卡银行及持卡人的银行账户的一系 列号码。虚拟卡号码(VCN)为不含有任何识别信息但与真实卡号(RCN)关联的一系列随机 产生的号码。
[0109] 数字钱包为实体钱包的电子形式且容纳各种支付方法(例如,信用卡、借记卡及/ 或预支付卡)及/或呈储值形式的电子现金。
[0110] 当前由数字钱包提供的益处中的一者为向商家隐藏消费者的RCN,从而允许消费 者从其不倾向于给予其RCN的商家进行购买。然而,向商家隐藏消费者的RCN的结果为商 家不知道哪一张银行卡正被使用且与所述特定银行卡相关联的任何促销活动被放弃。
[0111] 通过将VCN并入到数字钱包,消费者能够隐藏其账户信息同时显露发行所述卡的 银行,从而享受能够在不给出其RCN的情况下从商家购买的益处同时享受与使用特定银行 卡相关联的所有促销活动。
[0112] 现将描述现有支付选项。一种当前技术涉及经由信用卡、借记卡或预支付卡直接 对商家进行支付。如图11中所见,向消费者询问卡信息8001、配送地址(此处为商店提货 8002)及账单地址8003及类似者。参考图12,在支付的审阅期间,消费者通常审阅他或他已 在先前页面中输入的所有信息。商家能够获得来自消费者的信息(包含实际卡号一RCN)。 此选项是有利的,这是因为其不要求任何形式的注册,消费者有权享有他的卡给予的任何 特权,商家通过标准过程处理交易且在他或她的银行账户中接收他或她的结算,且现有纠 纷处理及/或退款过程是可用的。另一方面,消费者面临向商家显露他或她的卡号及安全 码的风险,且所述过程是麻烦的,这是因为所述过程要求消费者填写许多信息字段。
[0113] 另一当前技术涉及经由数字钱包间接向商家进行的支付。如图13中所展示,将消 费者重定向到钱包网站(例如,通过选择钱包选项"电子钱包"8004)。在图14,举例来说, 消费者使用他或她的电子邮件(或另一用户名)及密码登录到他或她的钱包账户。在图15 中,消费者审阅待用于购买的卡且点击"继续"按钮8005以确认支付且被重定向到商家站 点。在图16中,消费者审阅他或她的信息。在此选项中,RCN信息不被传递到商家。商家 仅接收到支付令牌。此选项是有利的,这是因为消费者仅需登录而非填写信息字段,且因为 消费者的卡号及安全码向商家隐藏。另一方面,消费者放弃其卡所给予的任何特权,且商家 在他或她的钱包账户而非他或她的银行账户中接收支付,且纠纷处理及退款过程对于商家 来说是困难的。
[0114] 又另一当前技术涉及经由虚拟卡号(也称为虚拟账号)与商家直接交互。此处,在 图17中,用户使用用户ID及密码或类似者在8006处登录,且在8007处被提供虚拟卡号。 在图18中,接着,用户将来自8007的虚拟卡信息输入到对应字段8008中。有利的是,消费 者的真实卡号及安全码向商家隐藏。另一方面,存在相对非直观的用户体验,其中消费者需 要离开当前交易以转到他或她的银行网站8006以产生VCN 8007 (通常通过在他或她的浏 览器的窗口与浏览器选项卡之间交换);此外,如同第一当前选项,这是需要消费者填写许 多信息字段的麻烦过程。
[0115] 现参考图19,现将描述根据本发明的实施例的示范性步骤序列,其中消费者经由 具有VCN能力的数字钱包进行远程支付。在8009处,用户选择具有VCN能力的数字钱包 "E-wallet"作为支付选项。因此,将消费者从商家网站重定向到电子钱包网站。在图20中 的8010处,消费者使用他或她的电子邮件或类似者登入或在他或她未拥有账户的情况下 注册账户。在图21中的8011处,通过姓名向消费者打招呼且显示他或她选择的个人消息。 如果所述姓名及个人消息两者均是正确的,那么他或她继续键入他或他的密码。在图22 中,消费者可选择已处于他或她的钱包中的RCN或VCN,如在8012处;通过点击紧挨着他或 她的RCN的"使用VCN"按钮8013来产生单个交易的VCN ;或通过点击"添加卡"按钮8014 来将新RCN或VCN添加到他或她的钱包。可提供用于添加及/或管理VCN的任选功能性。 如果消费者希望管理VCN规则、限制及警报,他或她可通过接口本身这样做。在右侧列中, 可提供各种配送地址选项,例如"住宅(默认)"、"度假屋"及"爸爸的房子"。图23为此管 理接口的非限制性实例。如图24中所见,在消费者已选择他或她希望使用的卡之后,他或 她将点击"审阅您的订单"按钮以被重定向到商家站点以完成他或她的交易;在8015处,商 家网站显示VCN而不显示RCN。
[0116] 有利的是,在此实施例中,消费者可产生待仅用于特定交易的VCN;消费者可创建 待用于不同用途的多个VCN且并可指定有效期限或VCN的可使用次数;及/或消费者可设 置对其VCN的控制,例如在(例如)以下情况下请求被提醒或使交易被拒绝:交易金额超过 规定限制、在VCN上花费的金额已达到其每日限制及/或特定类别的消费已达到其限制。
[0117] 在本发明的另一方面中,经由NFC钱包进行接近支付。除经由移动支付技术的远 程支付外,虚拟卡号也可用于接近支付。当消费者提防商家时可替代地使用VCN,而不是将 实际信用卡加载到钱包中。此方面的优势类似于上文针对远程支付方面论述的优势。
[0118] 图25展示示范性交易流程。在一次性先决条件(pre-requisite)及设置过程8017 期间,如在8020处所见,一或多个消费者598向数字钱包597注册,且在所述钱包上添加卡 及配送细节。此外,如8021处所见,商家1999与钱包597整合且将钱包的支付标记置于商 家的网站1999上。注意,参考字符1999在图25中用于指代商家及商家的网站两者。举例 来说,可使用模块1483或5483实行步骤8020、8021。
[0119] 在支付阶段8018中,如8022处所见,消费者598访问商家的网站1999或访问所 述商家的某个其它应用程序并进行购买。如在8023处所见,在结账时将消费者重定向到钱 包597。在步骤8024处,消费者选择现有VCN或创建新VCN来使用。在步骤8025处,钱包 597将VCN细节传递回到商家1999。在步骤8026处,作为结账审阅过程的一部分,向消费 者598展示所述细节。在步骤8027处,消费者598审阅所述细节并确认支付。在步骤8028 中,商家将所有信息传递到收单机构990,收单机构990经由网络987将所述信息发送到发 行机构(未展示)。在步骤8029中,网络987的运营商使用MasterCard丨nConirol? PAN (主 账号)映射功能性8016来访问表(table)或类似者,以在将RCN传递到发行机构(万事达 卡国际股份有限公司的注册商标,购买,美国纽约)之前将交易的VCN映射到对应RCN。
[0120] 在8019处展示其它过程。如在8030、8031处所见,结算及退款及/或撤销过程可 为常规的(即,正常营业或"BAU")。
[0121] 在一些情形中,如本文中其它地方论述,合适的应用程序12驻留在智能电话 1420、10或类似者上且向实体位置处的终端126或类似者出示此电话。应用程序12包含或 可访问一或多个本地存储的VCN及/或一或多个本地存储的报价5994。
[0122] 因此,本发明的一或多个实施例针对电子钱包(e-wallet)(也称为数字钱包)及/ 或结合电子钱包有利地起作用。如所提及,电子钱包向消费者提供用于对从受理的在线商 家的购买进行支付的安全且方便的方式。在注册之后,消费者可将其卡、账单及配送信息存 储在由合适实体(例如,支付网络2008的运营商)托管的站点上,且可访问所述信息以跨 越参与商家方便且安全地进行支付。电子钱包平台可使用"虚拟"账号提供额外安全性来 屏蔽持卡人的真实信息。
[0123] 在一些情形中,举例来说,上文提及的"虚拟"账号的使用(也称为PAN映射)可 为支付网络2008的运营商(例如,例如万事达卡国际股份有限公司的实体)向发行机构提 供的网络服务;在其它情况下,发行机构可选择使用其自身的解决方案。PAN映射过程涉及 获取原始主账号(PAN)且取而代之发行伪PAN(或虚拟卡号)。这提供了防止原始PAN可能 被泄漏的安全性。PAN映射的非限性实例为依据万事达卡国际股份有限公司的inControl? 支付解决方案平台的"一次性使用号码"特征所提供的PAN映射。所属领域的技术人员将熟 悉各种PAN映射技术,且鉴于本文中的技术将能够针对本发明的一或多个实施例调适PAN 映射技术。举例来说,支付网络运营商可创建转译表,其中数字的面向外实例呈现伪PAN,而 面向内实例呈现实际PAN。鉴于本文中的教示,可适于本发明的实施例的可市售PAN映射解 决方案包含爱尔兰都柏林,黑石,Carysfort大街,黑石商业园1街区的Orbiscom有限公司 (Orbiscorn Ltd. , Block 1, Blackrock Business Park, Carysfort Avenue, Blackrock, Co. Dublin, Ireland)(现在为万事达卡国际股份有限公司的分部,帕切斯(Purchase),纽约, 美国)购得的PAN映射解决方案;借助实例且没有限制,弗利克洛弗特(Flitcroft)等人的 美国专利6, 636, 833及7, 136, 835,所述专利的完整揭示内容出于所有目的以全文引用方 式明确并入本文中。
[0124] 为免生疑问,应强调,万事达卡国际股份有限公司的inControl?支付解决方案平 台为非限制性实例,且可使用许多不同技术来提供本文中在其它地方描述的"虚拟号码"而 无论PAN映射是如在弗利克洛弗特(Flitcroft)等人的美国专利中还是其它地方所描述。
[0125] 应注意,所属领域的一般技术人员将熟悉电子钱包本身,且鉴于本文中的技术将 能够调适电子钱包以实施本发明的一或多个实施例。已知电子钱包的非限制性实例包含贝 宝(PayPal)服务(美国加利福尼亚州圣何塞的易趣(eBay)有限公司的贝宝(PayPal)子 公司的商标);亚马逊结账服务(Checkout by Amazon service)(美国华盛顿州西雅图的亚 马逊(Amazon, com)有限公司的商标);及谷歌结账服务(Google Checkout service)(美 国加利福尼亚州山景城的谷歌有限公司的商标)。
[0126] -或多个实施例有利地在由电子钱包提供的方便用户体验中使用虚拟卡号。如上 文论述,虚拟卡号有利地提供递增的安全及消费者信任度级别(尤其在其中消费者不熟悉 正从其购买的商家的跨境使用情形中);实施警报、限制(交易的时间、金额及数目、商家类 别等等)的可能性;及/或风险管理。另一方面,虚拟卡号是不方便的,这是因为其提供麻 烦的用户体验,其中消费者需要在他或她的虚拟卡号产生器(浏览器、桌面插件程序等等) 与他或她的支付体验(商家站点)之间进行交换。
[0127] 如上文论述,钱包提供以下优势:消费者经由鼠标点击或类似者进行支付而甚至 不需要将他或她的卡从他或她的钱包中抽出(也不需要离开商家的网站);然而,这是不方 便的,这是因为在钱包应用程序将卡号传递到商家供处理的情况下消费者需要信任商家; 及钱包可或可不提供可向商家提供责任移转的风险管理水平。
[0128] 有利的是,一或多个实施例整合虚拟卡号与电子钱包。在一或多个实施例中,商家 不需要改变任何整合来以虚拟卡号使用电子钱包。此外,在一或多个实施例中,以虚拟卡号 对商家进行支付或以真实卡号对商家进行支付之间的差别对于商家是透明的。
[0129] 在一或多个实施例中,消费者能够仅使用几次鼠标点击或类似者在其支付体验期 间选择何时想要针对特定交易使用VCN。一或多个实施例的相关使用情形包含其中消费者 想要更好地控制特定卡号的警报及/或限制的情形或当他或她缺乏对他或她正从其购买 的商家或国家的信任的情形。
[0130] 现在考虑当前钱包支付体验。如图26中所见,消费者在他或她的购物车中具有若 干物品,且在8032处被提供选择期望的配送选项以及所要支付方法(例如,常规结账8033 或电子钱包结账8034)的选项的机会。在图27中,在8035处,用户使用凭证,例如,电子邮 件地址或移动电话号码向钱包识别他或她本身。在图28中,在8036处,用户输入他或她的 密码。在图29中,用户在8037处从若干不同支付卡中进行选择且在8038处从若干不同配 送地址中进行选择。在右侧列中,可提供各种配送地址选项,例如"住宅(默认)"、"度假屋" 及"爸爸的房子"。在图30中,用户返回到商家站点并确认细节。在图31中,向用户显示支 付完成页码。
[0131]VCN嵌入在钱包中的I付体骀
[0132] 现关注图32,在第一步骤中,用户处在大体上标示为8039的购物车处,具有展示 在8040处的从若干不同配送选项进行选择的选项且还被提供支付方法选择选项8041 (方 便)及8042 (电子钱包)。在图33中,在8021处,用户使用凭证(例如,电子邮件地址或 移动电话号码)向所述钱包识别他或她本身。在图34中,在8043处,用户输入他或她的密 码。在图35中,用户在8044处从若干不同支付卡中进行选择,且在8045处从若干不同配 送地址中进行选择。在图36中,用户选择针对给定交易使用VCN,如在8046处所见。在图 37处,用户任选地使用MASTERCARDINCONTROL?平台或类似者(万事达卡国际股份有限 公司的分部,帕切斯(Purchase),纽约,美国)改变VCN的限制及/或警报参数;功能性允许 客
当前第3页1 2 3 4 5 6 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1