CN105960654A - 用于对网页内容、虚拟商品和小额物品付费的方法和装置 - Google Patents

用于对网页内容、虚拟商品和小额物品付费的方法和装置 Download PDF

Info

Publication number
CN105960654A
CN105960654A CN201480064068.4A CN201480064068A CN105960654A CN 105960654 A CN105960654 A CN 105960654A CN 201480064068 A CN201480064068 A CN 201480064068A CN 105960654 A CN105960654 A CN 105960654A
Authority
CN
China
Prior art keywords
path
payment
transaction
certificate
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201480064068.4A
Other languages
English (en)
Inventor
周大海
罗斯·霍夫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Little Stone Co Ltd
Original Assignee
Little Stone Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Little Stone Co Ltd filed Critical Little Stone Co Ltd
Publication of CN105960654A publication Critical patent/CN105960654A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • G06Q20/38215Use of certificates or encrypted proofs of transaction rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123Shopping for digital content
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment schemes or models characterised by micropayments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请涉及电子贸易(即电子商务或电子支付)技术,且更具体地,涉及通过诸如因特网的通信网络对包括网页内容和虚拟商品的小额物品付费的方法和***。所述的一个实施例涉及在付款人和收款人之间进行电子支付的方法,该方法包括通过付款机生成安全电子交易,该安全电子交易包括一个证书,该证书具有设定交易规则的扩展。通过所选择的网络实体的支付路径,将该安全电子交易从付款机路由到收款机,路径中的每层层次结构上的网络实体将各自的证书连同各自的设定交易规则的扩展一同添加到安全电子交易。也描述了本发明的其他方面,诸如如何确定选择的路径。

Description

用于对网页内容、虚拟商品和小额物品付费的方法和装置
相关申请的交叉引用
本申请涉及2013年10月25日提交的序列号为2,830,855的加拿大专利请申请,并且要求在先加拿大专利申请的优先权。在先加拿大专利申请的内容以引用的方式并入本文。
技术领域
本申请涉及电子贸易(即电子商务或电子支付)技术,且更具体地,涉及通过诸如因特网的通信网络对包括网页内容和虚拟商品等的小额物品付费的方法和***。
背景技术
目前存在着通过万维网来对“媒体片”和/或包括网页内容和虚拟商品的小额物品进行付费的方法和装置的需求。网页内容可以是研究论文、特定行业出版物、博客、报纸、杂志、专业团体等,甚至可以是按每次观看的视频或直播节目付费的任何事物。例如,在视频游戏市场中,消费者完全是用虚拟世界创建他们自己的游戏,并且为游戏中特定角色购买从定制跑车到睫毛等的虚拟商品。
在这种背景下,万维网(及其他机制)使得找到并购买各种网页内容和多种虚拟物品成为可能。然而,用目前的购买方法存在许多困难。例如:1)缺少使支付像从人们从口袋里掏出一枚硬币在街角的商店购买一张报纸一样容易的真正的“无阻性”的支付方案。当今的支付***通常是繁琐的,并且具有高的不成比例的下行风险,也就是说,你真的想要拿出你的***,然后输入你的号码去买一份报纸吗?相对于交易的规模,所需的工作水平太高,因此通常会吓跑客户;2)跨境购买就算是有可能,也会很困难:北美的客户可以轻松地从北美卖家那里购买商品,但是一旦跨越国界就会变得越来越困难,也就是说,国际卖家不具有相同的付款方式,有些国家,现今几乎不可能从那里买到什么;3)不是每个地方都支持多种货币;4)确保当地法律及法规的遵从性;5)建立体系以防止洗钱或其他非法活动;6)大多数***是基于***的,并且相对于支付规模而言,其本身具有非常高的手续费,也就是说,关于$20交易的手续费,消费者和/或卖家已经学会接受该费用,但是一旦交易规模下降到一美元或更少,它不仅使人变得烦恼,而且在某些情况下是不可能赚取利润的;以及7)缺乏整合闲置资产用于小额购买的方法,例如,有16,000,000,000美元的闲置信誉度货币。
小额支付的早期历史:已经有大大小小许多公司在提供电子支付***方面做了很多尝试。在90年代,大约1995年的米利森特的数字设备公司(DEC)(康柏收购)和大约1999年的IBM小额支付是在这一领域的早期玩家。这些第一代***是电子货币、数字货币或电子代币,且大部分主要是不记名的而且不可追溯。所有的第一代企业的尝试都以失败告终或仅仅作为理论上的项目而留下。
1999-2004年间出现的第二代微支付***主要是以账户为基础的,其类似于银行允许资金从消费者账户转帐到供应商账户。大公司失败的原因有:1)电子支付的市场仍处于起步阶段,即,贝宝(PayPal)仅仅在1988年左右才开始,而且人们在很大程度上还没有接受这种支付方式,也尚未信任互联网,而2)典型的大公司的风格,像DEC和IBM公司在试图“拥有一切”,而不让别人受益和/或参与该生态***。
当今大型竞争对手:谷歌(Google)、苹果(Apple)、贝宝(PayPal)和亚马逊(Amazon)(即“四大”)是目前支持小额支付的大公司,但无一例外都是依赖于***公司,且因此要承受他们的高额收费。例如,1美元的交易的成本为1.5%到2.9%或更多,加上$0.10至$0.30,这对于小额交易来说开始变得非常昂贵。另外,如果交易涉及货币兑换,则可能增加1.0%至3.0%的额外费用,并且这仅仅是收费的开始。此外,谷歌播放(Google Play)和苹果的iTunes(Apple iTunes)还要对销售内容、应用程序等收取10%-30%的巨额费用。亚马逊(Amazon)和贝宝(PayPal)每笔交易收费5%和$0.05。
综上所述,该“四大”公司具有以下问题:
·“四大”公司中没有一家是无阻性的:这“四大”公司都需要几次点击才能进行购买;
·费用:费用高得不成比例;
·没有提供将货币输入到***中的替代方式:现有***不允许用户使用信誉度货币和运营商代扣;
·并不是真正的全球化:这些现有的***并没有达到提供全球支持的程度,他们并不支持全球范围内的购买者使用任何货币,包括使用信誉度货币;
·自身不具备竞卖功能;
·不控制广告内容;
·欺诈防范能力不足:现今是通过售后来试图解决网络欺诈,即在诈骗行为已经发生后处理诈骗问题,这已被证明是无效的;
·有限的生态***:现有的***专注于提供封闭、有限的***,该***既没有用于购买全球内容和虚拟商品的全球性***,也不允许供应商合作伙伴和金融合作伙伴随意访问。
大型***公司:维萨(Visa)和美国运通(American Express)在这领域已经获得有限的成功。维萨于2010年在澳大利亚开始短暂的尝试推行点击付费,但是后来取消了该业务。美国证券交易所(Amex)提供预付卡服务产品,这本身并不是真正的小额支付的解决方案。
中型竞争对手:总部位于爱荷华州的Dwolla是一个自动结算所(ACH),并且已经在当前银行网络之外创建了网络。他们对转账的收费非常低:低于$10.00时是免费的,并且对金额大于$10.00的转账统一收费$0.25。总部位于法国的HiMedia公司是一家支付供应商、内容发行商和广告网站。总部位于旧金山的Paymentwall公司提供5%的货币化内容加上***费用的服务。此外,他们还能够支持运营商代扣、充值、银行转账和借记转账。总部位于德国的小额支付(Micropayment)公司与Paymentwall非常相似。
但是,所有这些中型竞争者仍然有未解决的问题:
·在该领域仍然没有无阻性的玩家;
·很少有(公司)能提供他们自己的地理位置之外的或全球性的解决方案;
·不支持信誉度货币;
·没有公司可以完全控制广告路径和收入;
·他们的解决方案要么是:1)专有或2)仍然在很大程度上依赖于***网络或3)以地域为中心的运营商。
移动设备:直接运营商、银行&第三方解决方案:有许多运营商和/或银行在相对的地理中心区域内共同合作来提供移动购买解决方案。客户能够通过以下方式购物:1)短信服务或发短信,直接从客户的账户(通常用PIN号码)扣费,2)WAP(无线应用协议),其在大多数情况下,要么绑定***,或通过贝宝(PayPal)或客户的运营商代扣,3)近场通信(NFC)设备通常用于店内购物,4)基于云的解决方案,这通常仍需要NFC硬件(谷歌(Google)、贝宝(PayPal)),和5)银行/运营商的解决方案。
该NFC解决方案和其面临的挑战并不是真正的相关,因为他们并不是为在线交易而定制的,即他们更多地专注于实体店购物。其他解决方案具有以下缺点:1)他们仍然需要***或传统的银行业务关系,且因此承受高收费,2)短信和代扣解决方案也对供应商收取高额费用,3)他们不具备向客户提供任何利用替代货币,诸如信誉度货币或优惠券,的能力4)在短信服务的情况下,没有为客户提供调解或追溯所购商品的查帐索引功能5)他们仍然需要多个步骤来购买物品,因此并不是无阻性的,和6)它们通常是以地域为中心的而没有足够大的资源提供全球性小额支付。
小公司:事实上,在该领域中几乎所有的小公司都需要支付处理器(诸如贝宝(PayPal)和谷歌(Google))以及***公司,因此在每笔交易2.9%的费用上再加上$0.30。许多这些服务发生在购物车和全包式市场之间的某些地方。属于此类型的公司有Payloadz(每月$14.95加上5%的交易费),Shopify(每月最少$29加上***费用),Volusion(每月最少$15加费用),FetchApp(每月$5.00-$500加上费用),Quixly(每月$10加上费用),Click银行(每笔交易7.5%加上$1.00),Pulley(每月$6-$299)和E-junkie(每月最少$5加上费用)。许多此类公司提供该内容并收取月租费。对于低带宽内容的费用和相关收费的范围为大约6-8%,而对较高带宽的内容,诸如视频可能花费超过12%。相较而言作为新手,Gumroad不需要支付处理器,但仍然要求使用***支付。每笔交易,Gumroad收取$0.30的固定费用加上5%。所有这些都是具有有限的灵活性的昂贵的***,因为他们是为有限和特定的目的而设计的。
社交媒体和游戏卡公司:诸如脸书(Facebook)的社交媒体公司也开始在游戏中使用虚拟货币,虽然他们主要的重点迄今为止仅仅是网络游戏。例如,另一家公司,Flattr,已经使得将资金绑缚到脸书(Facebook)的“爱好”界面成为可能。这里还有上百个游戏卡解决方案。
目前社交媒体和游戏卡的解决方案存在以下问题:
·大多数游戏卡并不是可转让的,因此其使用范围有限,即,他们不能在几个制造商的游戏之间跨越使用,或用于其他目的,诸如购买报纸、电影等;
·卡仍然不是无阻性的,仍然需要几次点击才能购买物品;
·对于供应商来说,没有机会利用跨平台的方式购买/广告数据;
·通常并非全球性;
·没有机会利用全球性信誉度货币;
·不能提供有效的欺诈防范和对限制条件的精细控制。
因此,在电子环境中需要一种改进的对小额、虚拟和其他商品付费的方法和***。
发明内容
本发明的目的是提供一种改进的方法和***,用于在电子环境中对小额、虚拟和其他商品进行付费,该方法和***缓解了现有技术中的上述问题。
本发明的一个实施例涉及在付款人和收款人之间进行电子支付的方法,该方法包括:通过付款机生成安全电子交易,该安全电子交易包括一个证书,该证书具有设定交易规则的扩展;通过网络实体的付款路径将安全电子交易从付款机路由到收款机,该网络实体中的特定个体将各自的证书添加到安全电子交易,每个各自添加的证书具有设定交易规则的扩展;并且在付款机处接收安全电子交易,包括接收来自付款路径中的每个网络实体的证书。
本发明的第二个实施例涉及在付款人和收款人之间进行电子支付的***,该***包括:付款机;收款机;和将该收款机和该付款机互相连接的网络;该付款机***作用于:生成安全电子交易,该安全电子交易包括一个证书,该证书具有设定交易规则的扩展;并且经过网络通过网络实体的付款路径将安全电子交易从付款机路由到收款机,该网络实体中的特定个体将各自的证书添加到安全电子交易中,每个各自添加的证书具有设定交易规则的扩展;以及该收款机***作用于接收安全电子交易,包括接收付款路径中网络实体中特定个体的证书。
附图说明
结合附图和以下详细描述,本发明的其他方面和特征对于本领域的技术人员将是明了的。
本发明依赖装置的结构、布局和各个部件的组合以及方法的步骤而存在,借以达成的预期的对象将在下文得到更充分的阐述,在权利要求中特别指出,并且在以下附图中进行示例,其中:
图1是示出了客户将如何被连接到内容供应商(在本例中,以华尔街日报为例)的实例;
图2示出了初始设置的信息流,客户从她的ISP(因特网服务供应商)接收“优惠券”;
图3示出了客户请求网页以及华尔街日报(WSJ)发回支付请求而不是页面-该支付请求带有了解华尔街日报(WSJ)的银行的信息的信息流。
图4示出了客户用于询问CH1(结算所1、她的ISP的结算所)到银行2和银行3的路径的信息流;
图5示出了用于每条路径的计算,其结果是得到使用该路径(即,沿着该路径通过每个实体发送支付)的精确费用;
图6示出了呈现给客户的选择-实际上,伴随着客户的最终选择的瞬间竞卖也正在进行。做出选择之后(在本例中,通过ISP)会示出信息流用于客户询问她的ISP来验证该支付;
图7最后示出了客户能够将支付凭证发送到华尔街日报(WSJ)(内容供应商)并且接收该页面的阶段;
图8示出了结算所的层次结构-每一层均作为其子节点的支付保证;
图9示出了证书的详细信息;
图10示出了路径是如何计算的;
图11示出了返回路径的样子(带广告网址);
图13示出了优惠券的范本;
图14示出了购买操作的示范性方法的流程图;
图15示出了对于ISP订户购买操作的示例性方法的流程图;
图16示出了对于专业协会成员购买操作的示例性方法的流程图;
图17示出了示例性购买方法的具体流程图;
具体实施方式
在下文中结合附图,对本申请公开的方案中各个方面涉及到的几个实施例或具体实施方式进行说明和描述,其中相同的参考标号用于指代相同的元件。在几个实施例中,当前公开的各个方面发现,实施例中在使用的HTTP协议(超文本传输协定)通过万维网进行的交易具有特定的效益;但是很显然,也可以使用很多其它协议(标准的或专有的)。
同样,实施例是用网页作为购买的商品进行描述的,但购买的商品同样也可以是在游戏中的物体(像游戏中的贵重的剑)、打折优惠券或者能够通过数据位来表示的其它任何事物。
另外,这些实施例中使用了X509证书;这仅仅是为了方便,因为X509被广泛使用。可以使用任何其他的加密签名方案替代X509证书。
现在参照附图,其中图中展示的内容仅仅用作说明该示例性实施例的目的,并限制所要求保护的主题,图1提供了支付***,通过该支付***消费者能够付钱给供应商(在本例中,供应商为华尔街日报)。通常情况下,会有很多资金流向的“路径”。在图1中,有如下可能的路径(ISP表示“互联网服务供应商”,CH表示“结算所”,WSJ表示“华尔街日报”):
1)客户->ISP1->CH1->CH3->银行3->WSJ,
2)客户->银行1->CH1->CH2->银行2->WSJ,或者
3)客户->ISP1->CH1->CH2->CH3->银行3->WSJ。
我们将ISP1,银行1,银行2和银行3称为支付机构(PA)。每个PA能够代表客户(消费者或像华尔街日报的供应商)处理支付(以及接收)资金。在某些情况下,我们将CH1称为ISP1和银行1的父级,将ISP1称为消费者的父级,以及将CH1称为消费者的祖父级。
如图1所示,在典型的场景中,消费者105用她提供连通性的ISP(ISP1)浏览网页。她点击到华尔街日报(WSJ)的链接,(也许该链通过搜索获得,或来自另一个网页的推荐,这是无关紧要的)。我们要解决的问题是华尔街日报(WSJ)如何要求付款,以及要求她如何支付所要求的金额,并且要以“无阻性”的方式做到这些,甚至是在跨境,多币种的情况下。
参考图2,消费者105最初通过从她的ISP1(或者任意一个和她有协议的其它支付机构)中得到“优惠券”205而加入该***。当她提供了令人满意的凭据(当然,各支付机构可以选择任何他们想要的-用户ID/密码,来自硬件认证令牌的动态密码等)时,优惠券205将被发送回并放入她的电子钱包210中。电子钱包可以是她的浏览器所支持的任何电子钱包210。如果ISP1发生支付违约,优惠券205将被加密签名,并将CH1作为支付担保人。ISP还可以把其他的信息放入优惠券205中-例如,这个客户已经订购了一个CA$5.00的月套餐。
参看图13,在这种情况下,优惠券文件1300具有将消费者105确定为付款人(ISP1)的字段。PFP字段是消费者105能够用于随着所需要的任何路径调整(当ISP1不想提供PFP时,而使用CH1的PFP替代)来查找路径(涉及ISP1)的URL,PFP字段也是将优惠券识别给客户的一个名字(在此情况下,像“来自ISP1的每月$5”的一些东西)。也有优惠券类型的说明(在本例中为,一个月CA$5)。消费者或者更准确地说消费者的浏览器)能保留像可用预算的一些字节来追溯还有多少预算没有花费掉。
优惠券的类型非常广泛-从各种不同的货币到信誉积分,到订阅服务(在一个时间段内的X次访问),到用于自由访问的特殊交易或诸如此类的广告交易。用户扩展部分同样***-在优惠券的范围内,从仅仅保留剩余的预算到保留在这个优惠券下的购买的完整历史记录。
参考图3,消费者105通过点击华尔街日报(WSJ)的链接(1)发起交易。对于HTTP而言,发起的功能有点像“获取物品-URL”,其中,“获取”请求一个网页,然后“物品-URL”识别购买的确切物品。值得一提的是,HTTP指定了返回IP、所需的语言[S]、期望的格式[S]以及其他信息。
然后华尔街日报(WSJ)网络服务器通过任何商业逻辑(可动态地根据时间、用户等)来决定是否要收费,以及收费多少。假设决定要收费3分钱,则送回支付请求。在HTTP中,这可以由保留为所需支付的状态代码402或用于认证的状态代码401来完成。不论哪种情况,华尔街日报(WSJ)网页服务器都会定义金额、货币的规格以及有关支付必须如何处理的信息。在本例中,华尔街日报(WSJ)已指定支付必须通过银行2或银行3进行。这纯粹是由华尔街日报(WSJ)选择的银行或其他支付机构来决定。华尔街日报(WSJ)可以在类似于图2的过程中获取银行信息。请注意,多数情况下,华尔街日报(WSJ)可能会发送回带有每种价格情况的价格单。华尔街日报(WSJ)会将处理该支付的PA(本例中为银行2和银行3)清单连同价格一起发回。
参考图4,消费者105现在知道要付多少钱,但需要找到支付方式-也就是说,她需要找到将该支付从她传递到华尔街日报(WSJ)的实体链。这通过借助一些实体的“路径查找器”功能来确定在她和华尔街日报(WSJ)之间一个或多个可用支付路径。这通常是通过浏览器扩展来完成的;浏览器扩展在优惠券205中寻找ISP1从而找到PFP URL,然后向PFP请求获取路径列表。她将预期目标(银行2和银行3)的列表发送到ISP1。然后,ISP1返回能够从ISP1到银行2或银行3的路径列表。(请注意,每条路径的终点只能是银行2或银行3中的一个,但通配符符号可能对于指示可到达所有目标终点的路径是有用的。)。返回的路径信息包括节点链,以及使用每个节点的费用表。使用每个节点的费用表可以为简单的固定金额或可基于支付量和货币兑换费的计算得到。
图11示出了路径是如何返回的。每条路径包括多个节点,并且每个节点将指定使用该节点的成本/费用以及进入/离开该节点的货币。每个节点必须具有全局唯一的标识符。可使用任何编号/命名方案,诸如ASN.1,或UUID(见http://en.wikipedia.org/wiki/Globally_unique_identifier),但最简单的就是使用域名。由于每个节点都必须呈现在互联网上,无论如何都需要域名且DNS保持唯一性。该费用是该节点的收入且包括操作该节点的成本加利润。本申请实例中的该费用可以指定为一个固定的价格,也以可为一个百分比,或者任何公式。此外,该费用可以是如同HTTP://mydomain.com/advertPage之类的URL(统一资源***)形式的一则广告。此外,可以通过向消费者报价的特殊交易URL来使得该费用令人满意;如果消费者接受了这笔交易,预期的交易将会完成而无需支付操作。
在这个实例中,路径与ISP1对应,它在开头隐含ISP1。该路径中是否明确包含ISP1是可选的。这两种情况下,都执行相同的过程。该PA(在本例中指ISP1)也能够检查其父级是否的确是下一个节点。
通常,出于效率的考虑,希望CH1能能够预先计算该路径,而不是计算请求的路径。所以很自然地就得到路径信息的费用表,消费者就能够容易地计算每个路径的费用。下文中描述的实例遵循这种设计。一种备选的设计是用于消费者沿着路径请求发送支付明细,在这种情况下,CH1可以代表消费者105执行计算和发送回该(计算)结果。
参考图5,消费者105现在将使用每个节点的费用表来计算沿每个路径的费用。作为备选,CH1可能已经提前完成了这一计算。不论哪种情况,消费者105现在具有所有的交易明细,在该交易明细中,她知道沿着路径的每个实体,以及沿着该路径的每个实体的收费金额/货币。该信息对于遵从各种地方或税法要求是有用的,并且该信息在涉及该交易中应该沿着每个实体传递。在该实例中,华尔街日报(WSJ)收费US¢3,银行3增加US¢0.1,CG3增加US¢0.2,CH1按1.1的汇率转换到CA$,这增加了CA¢0.1;因此对于消费者105的总费用为(3+0.1+0.2)*1.1+0.1=3.3*1.1+0.1=CA¢3.73。
参考图6,她的浏览器会弹出显示她必须支付的选项的窗口605。在本例中,她有两个选择:请求她的ISP1从CA$5.00中支付出CA¢3.73(其中剩余CA$4.9627),或请求她的银行1支付CA¢4.2(使用与上述类似的计算,除了已经添加的银行费用)。注意,在使用小于一美分的零钱上并不困难,可采用删除或四舍五入的计算,尽管已签约的交易应注明已经使用了哪种方法。在这种简单的竞卖中,她会选择使用她的ISP1中的月套餐这一更便宜的选项。她的浏览器将会把支付明细发送(包括路径、每个实体的收费、关于将要购买的物品的明细)给她的ISP1。然后,ISP1将执行需要的任何身份验证和授权(这一过程非常随意,须遵从当地法律或任何公司指导方针等)。如果授权支付,ISP1将加密签字支付并将证书610发回给客户105。客户105可以更新她的优惠券205以表明已花掉了3.73美分。
和任何其它支付***一样,需要对付试图进行欺诈的流氓实体。例如,CH1和ISP1之间的协议可限制ISP1每天可支付的金额。如果ISP1“变流氓”并且签发更多的证书,这将会有问题。这个问题通过允许每个实体设置如何确认支付的说明而得到缓解。这允许将CH1设置在ISP1证书中,从而使得收款人必须联系CH1来确认支付。显然,对于每个实体来说可能并不希望每笔交易都确认-因为这样带来的额外负担开销会降低效能;所以我们允许说明包括此类内容:如果该ISP今天已经认证了100个交易到收款人,那么必须确认每笔交易,否则(对于前100个交易)随机确认交易的1%。随机选择可以通过将交易明细散列在一起而制成以形成随机数。通常,像华尔街日报(WSJ)这样的内容供应商不期望写代码来进行这些检测,他们会打电话到图书馆或使用HTTP以访问由他们银行提供的服务器。
参考图7,消费者105将证书610发送到华尔街日报(WSJ)。华尔街日报(WSJ)使用常规X.509来检查证书610从而确认证书610的身份和有效性。然后华尔街日报(WSJ)按照说明来确认支付(如有必要的话)。确认付款之后,华尔街日报(WSJ)服务器就可以将页面705按照要求返回。
也可能存在许多其他可能的变型和组合。
图2示出了消费者105从她的ISP1获得$5/月的优惠券的流程。这只是ISP1可以提供这种服务的众多方法(类似可用于基于手机和短信的众多方案)中的一项。这可能是每月的包月费,也可能是具有最低值的按次计费,也可能是在$5/月的使用情况下只收取$2。一般来说,ISP1可以任意地将其打包和任意收费。虽然这个***不会对ISP1施加限制,但是存在客户是否会接受它这一限制的问题。
她可以很容易地将她的银行、雇主或其他任何第三方来充当支付机构而不是让她的ISP成为支付机构。例如,AMA(美国医学协会)可能会很想这样做,以将它作为其成员的福利。更重要的是,AMA能够与某些网站进行特惠协商以获得折扣。内容供应商将通过对相同的页面指定多个价格来实行此类折扣-如向AMA收费5美分,CMA6美分(加拿大医学协会),其他人7美分。作为备选,该价格可以是7美分,但折扣X、Y、Z是可用的。这一过程的完成甚至不用在网站上做改变;即,AMA(作为支付机构)将通过依据附加协议做出的只支付5美分的一个说明证明其完成了7美分的支付(在本例中,协议将不得不在结算所登记以完全自动完成这一过程)。该协议不必对每篇文章定价,他们可能是批量定价,全部一次总付访问,也可以是协商的任何方式。在最简单的形式中,该节点的费用可以被指定为URL。该费用URL将采取包括交易明细的标准的参数列表,且它将返回实际费用列表(如同所述费用在路径中)。换句话说,费用URL允许对从路径建立时间到实际使用时间内的实际费用进行延迟估算。最大的优势是交易明细是可获得的-允许对于特定用户、时间、天气、国际事件等情况的特殊交易。
可以使用其他货币而不必使用当地货币形式的实际金钱。例如,可以使用信誉积分(例如航空积分里程)。支付机构可能是相关的航空公司(或其合伙人)以及可用于信誉度账户的优惠券。该航空公司还可以充当货币兑换机构以将积分兑换成实际货币。航空公司还可与特定内容供应商(见下文)达成协议。
消费者有可能免费获得虚拟商品而无需付费。例如,供应商发送回一个价格可能为0美分,但将显示广告。这与一些网站现在正在实行的方式一样,但消费者现在可以选择是否愿意支付,或接收广告。
不仅仅供应商是可以卖广告的,第三方也可以。例如,AA(美航)可能想卖广告给正在阅读旅游目的地的人们。此外,AA还希望根据被浏览网页的性质或主体而定制广告,即根据网页是否是在福布斯杂志而不是在体育画报来改变广告。AA可以通过与具有适当资源-比如威瑞森(Verizon)公司的ISP对话而完成这一过程。威瑞森(Verizon)公司(作为支付机构)每次被要求为福布斯标记为“旅游”的文章付费时,它都能发送回显示“带有AA的赞美词”和URL(统一资源***)的路径。浏览器使用URL弹出显示头等舱舒适性的窗口。对于体育画报,弹出窗口可能显示便宜的票价。谷歌广告联盟(及其它)提供了一些这方面的功能,但是用这些***时,通常广告客户必须要经过谷歌***或类似的***(即与供应商签署协议的)。与此相反,在本发明中的***允许沿着支付链的第三方来获得这种能力。
进一步的变化是,广告能够提供任意性质的特殊交易。这可以通过在路径信息中返回的URL来实现。
参考图8,“中央结算所”805为“加拿大结算所皇家银行”810(通过加拿大皇家银行操作的结算所)签发证书。该证书可以通过常规的X509方式来签署,即,RBC Ch810将它的公钥和其他信息交给中央CH805,中央CH805在证书上填写RBC CH 810信息,加上它自己的信息并签署证书(用它的私人密钥)。转而,RBC CH 810为支付机构ISP1 815和银行1820签发证书。在这个实例中,通过ISP1承诺的任何支付由RBC CH 810(在证书中统计限制范围内)担保,类似于通过银行1承诺的支付。
中央CH是不必要的,第一层CH810、825、830可以彼此认出彼此(就像标准的X.509,其中每个浏览器都有它们愿意识别的认证中心的列表)然而,当有许多第一层CH810、825、830时,中央CH的存在可能在管理上更简单一些。
结算所和支付中心很可能有很多层。例如,图8示出了为子银行1 835(其为支付机构,也可称作子PA)签发证书的银行1 820(其也为支付机构)。
参考图9,该证书是标准X.509证书,其具有用于限制说明的我们的扩展。该证书基本上是由发行人(在该实施例中为RBC Ch810)做出的一个承诺,该承诺用于担保任何由主体(在本实施例中为ISP1)承诺的支付。预计,RBC Ch810可要求ISP1将一定金额的保证金存入RBC CH 810作为支付保证。
显然,该保证只有当ISP1对其承诺的付款违约时才有用-换句话说,ISP1已经变成无赖并且可能疯狂地发行不打算继续兑现的承诺时。即使对限制到一分钱的每笔支付,ISP1都有可能可发出很多承诺且未兑现的承诺会累计至百万美元,这远远超过了任何保证金存款。
显然,这对于RBC CH 810来说,保证ISP1所有的承诺将是非常艰巨的任务,RBC Ch810可能没有做出任何这样的保证,并且当最坏的情况发生时,并没有足够多的保证金来偿还。本发明的中心部分是“限制指令”,其将风险限制到了可以接受的程度。限制指令被放入到扩展中(定义在标准X.509中)。任何想依靠发行人担保的用户必须遵照适用于每笔交易的这些说明。
该说明的形式很多,以下所列为其典型的形式:
·如果该主体或支付机构(在本例中为ISP1)已经在Y分钟的时间跨度内向收款人做出X笔支付,那么该交易必须经发行人(在本例中为RBCCH)验证。
·如果这个主体已经向收款人总共支付了Z美元,那么该交易必须经发行人验证。
·取散列交易并把它作为随机数。如果随机数可被W整除,那么本次交易必须验证。
·如果该主体发生了一个被拒绝的交易,那么以后所有的后续交易必须经过验证。这是由收款人/供应商强制执行的,但是因为担保人做出了拒绝,所以欺骗是很容易被检测出来,所以收款人的任何后续交易都可以被检测出。
发行人验证交易是指交易被发送到发行人并且发行人将返回是(Yes)或否(No)的回复。该机制设计用于给予发行人阻止任何流氓主体/PA太过猖狂的机会。例如,上述前2个典型的说明将有助于限制流氓主体/PA可以移动到任何特定的收款人的金额。任何流氓主体/PA很可能与少数的用户勾结,因此实际上我们有效限制了流氓主体/PA所造成的总的损害。
上述后2个典型的说明允许发行人在达到限制条件之前停止向其他收款人的支付,这进一步限制了损害。
如果流氓主体/PA勾结的用户数量巨大;请记住每个收款用户必须有自己的PA,因此没有必要追着每个流氓用户要求补偿。可以简单地跟踪那些流氓用户的PA。
由于一些原因(限制损失是一个原因),可以很方便地将有效期(已经出现在X.509标准中)限制在一天甚至更短的时间内。这与标准X.509的使用形成鲜明对比,通常在标准X.509的使用中证书的有效期有好几年。这样做的结果是,证书处理必须自动化,即,ISP1必须能够从RBC CH得到它的日常证书以及来自ISP1的每个用户。通常,这将作为所说的网络服务而实现,并且每个用户(更准确地说,用户的浏览器试图做当天的第一笔交易时)将出示凭证并获得证书。注意,在有效期内所有的交易都是由证书路径上的实体担保的,在本例中该实体为ISP1和CH1。欺诈限制机制保证有效签署交易的支付,同时防止欺诈行为。
限制说明也可以用来防止“洗钱”,因为洗钱类似于流氓PA发送大量交易到许多不同的收款人。
对于许多供应商,具有非常短期的订购服务是有用的。例如,华尔街日报(WSJ)每篇文章可能会收费3美分,或10篇文章收费25美分,或每天收费1美元最多可获得100篇文章。这可以被放入价格选项中且客户可以选择。该***能够自动记录选择了哪些套餐,以及购买了哪篇文章;华尔街日报(WSJ)通过向客户发行优惠券(参见图13)就可很容易地实现这一功能。具体而言,支付证书(由她的ISP签发)将用于比如一个10篇文章的套餐,然后将导致一个优惠券被放入到她的电子钱包中。后续文章将用如“10个中的2个”这样的序列号援引优惠券来支付,两端都可以确认是否超支。优选地,它们的交易都应由消费者签字以使风险最小化,但这取决于消费者(也许计算机太慢)。因为华尔街日报(WSJ)本身发行优惠券并检查每笔交易,华尔街日报(WSJ)可保证订购限额是受尊重的。
对于任何交易,建议每个参与实体都有交易的完整明细。这主要是为了易于遵守当地的法律;但是,这使得每个实体有可能积累消费者数据。考虑到数据库的当前状态,存储每一单交易并完全索引它们用于快速检索是很有可能。这些数据对于客户识别和其他广告目的是非常有价值的。
由于审计和其他原因,所有的交易流回到一个中心点用于安全保管将会是方便的。例如,这个中心点就是可以检测到流氓支付机构超支的点。这个点也是我们检查支付要求是否有效(也许没有遵照证书中的确认说明)的点。在大多数情况下,我们希望每个节点(无论是结算所还是支付机构还是子PA)来维护自己的审计和税务档案。
对于每个实体来说,将所有的交易发送到中心点可能是毫无意义的重复。每个支付机构可以简单地把他们所有的支付证书“在层次结构之上”发送到他们的结算所。然后,结算所再转发给中心点和/或将该证书与供应商的支付要求进行匹配。
尽管做了所有的努力,争议还是会发生的。解决该纠纷的一种方法是这样做,***支持-不支持交易,因此,退还消费者在供应商的消费。这在管理上是昂贵的,而且使消费者不高兴,供应商更不高兴。本发明的***允许新的机制,其中可以允许每个消费者进行几次“无疑问的”撤销(其中“几次”是由支付机构定义的,可以是诸如“基于月支付累计值,每月多达3次”这样的内容)。消费者可以将付款证明提交到她的支付机构(或结算所,或中心点)且该付款在没有将资金从供应商要回来的情况下将被撤销。当然,关于每个消费者和供应商的不良交易数量的统计数据将会被保存。只要消费者/供应商有多次不良交易,就可以采取行动,即终止关系,提高月费,提高手续费等。
路径计算
乍一看,会以为路径查找器是复杂和资源密集的过程,因此没有实体将要提供这项服务。事实证明,路径查找器是广告的关键,因此谁控制了它,谁就控制了挣钱。优选的方法是,每个人都开始提供这项服务;为了简化术语,我们把想要做这项服务的任何实体都称为“付款人”。最简单的方法是让每个付款人提供一个PFP(路径查找器门户网站),且用户将它的PA作为第一付款人,然后要求每个付款人获得路径和父级,然后要求父级获得更多的递归路径。这是完全行得通的,但强制用户通过网络对大量不同的实体做大量的查询;这意味着该过程很可能是缓慢的。
推荐的方法是让每个PA PFP一直为其本身及其父级PA和/或CA在证书层次之上返回路径。由于用户只能看到和处理PA的路径,这对于父级PA和CA来说是***广告的最方便的方式。
另一个建议方法是将广告信息脱离支付路径,但允许每个实体提供用户能够查询广告交易的门户网站。
显然,每个付款人及其父级必须有用于更新路径信息的协议。我们希望,通常,父级会每日下载路径信息(可能包括日期范围-这对于有时间限制的广告是特别有用的)。通常,钱包中的每个条目将包括付款人职责,以及PFP信息。
路径计算看起来可能令人生畏,但它实际上相当简单。让我们对若干不同的实体做一些估算(这些都是为了解计算规模而进行的真实的大致的估算,有的可能时通过数十个甚至数百个影响因素算出):
·国家结算所-在范围上大致可称得上是“国家”结算所,但由于竞争使得每个国家可能仅有几家国家结算所。也就是说全世界仅有一千家这样的结算所。
·专门性结算所-这些都是信誉度积分以及类似物,也有一千家。
·PA(支付机构)-这相当于大银行或大财团,可能在主要国家有近上百家,而在小国家却只有几家。全世界共计1万家。
·付款人-这相当于ISP或本地银行。假设有十亿用户,子PA的数量不可能超过一百万(否则,大量的子PA将负责非常少的用户,这不经济)。
由于路径是从付款人到付款人,假设有一百万个付款人,我们正在寻找一兆个端点对,加上每对端点之间的多重性路径(基于货币等原因)。可能,我们正在寻找数百兆的路径。
幸运的是,每个付款人都有更简单的问题-它们仅仅处理将自己作为起点的路径。这也只需要处理一种货币。例如,ISP1将只返回具有ISP1-Ch1-…的路径并且将不必处理具有银行1-CH1-…的路径,这就大大简化了ISP1的问题。事实上,ISP1可能仅仅从CH1得到整个列表而放弃用于特殊交易的机会,或ISP1仅仅为CH1提供PFP(参见图13)。这意味着每个付款人将只需要担心到达每个远端付款人的路径。
如果该付款人将这些路径存储在相关数据库上,比如说远端付款人的索引表,每行都是到该付款人的路径列表。每条路径上都可能有十家实体,每家实体用比如说一百个字节来描述费用等。使得每条路径在1K字节以下。如果我们很大胆地假设到每个远端的路径有10条,我们查找的每行都有10K字节。因此,该表将有一百万行,每行有10K字节。整个数据库约10G字节。按照现代的标准,这是个小型的数据库(但可能仍然需要为获得最佳性能而进行调整)。
每个付款人(或任何其他实体)能够预先计算到所有端点的路径并预先填充表格(预先计算或预先填充表格比如说可以在从它的父级PA接收到每日的下载之后的每个晚上)。在传输过程中也可能计算出路径,并且能够缓存结果以便后续查询。每个付款人可自主选择在何时计算或重新计算路径。
我们还希望在一些情况下,数据传送会是巨大的-例如,向PA请求其付款人的列表可能是多兆字节。为了提高效率的目的,协议因此可以配置成以“从N版更新”的方式或“即时更新”的方式进行操作。
我们分层地解决路径计算问题:参考图10,每个CH和PA将计算到所有其他PA的路径。由于证书层次结构是树形的,该算法将起作用。每片叶子(无子PA的最低后代PA)将轻易地完成该算法-它没有去任何地方的路径并且当被请求时将返回空值的或空集。如果所有的子代都成功地返回各自的路径,那么每个节点(CH或PA)将完成这个算法。由于该证书层次结构是树形的,那么能够保证在有限时间内收敛并完成该算法。总的来说,叶子会先完成,然后路径将会冒出直到所有的节点都完成为止。
再次参照图10,每个CH和PA分别通过识别子代列表而开始,即,已经签字的PAs列表。CH/PA的路径表被称为我的路径;开始时,该表设置为空。对于子代列表中的每个子代:
·将由“子代”组成的路径加入到我的路径。
·向每个子代索要其路径清单,称它为子代路径。
·对于子代路径列表中的每条子代路径:
o检查子代和子代路径的头部是否具有兼容货币(注意,对于一个特定的节点可能兼容货币X,但不兼容货币Y);
o对于每个兼容性的货币,将路径添加到由<子代、货币、子代路径>组成的我的路径。
CH/PA然后简单地将我的路径数据保存在表或数据库中。
结算所将期望获知彼此以及彼此之间的连通性。这是合理的,因为这些信息并不经常改变,且CH的数量很少。在任何情况下,各CH必须集中注册,所以容易获得这种信息。
一般的实例,实施购买:
如上所述,本发明的方法和***可以以多种不同的方式来实施。为了完整性,下文将更详细地描述几个这样的实施方式。本发明的一个这样的实施例可以按如下方式实施(见图14):
1.搜索引擎(或任意网页)将用户指向网站(1410)上的页面。注意,像广告,搜索结果可能是在结果页面上的付费链接,其是完全独立于对内容付费的操作。
2.用户点击链接意味着浏览器确实执行HTTP get(1420)。
3.没有本发明的***时,该网站将返回页面HTML(通常使用意味着完成的HTTP状态代码200)。使用本发明的***,该网站返回带有具体价格的支付请求(1430),比如说该页面收费1美分。该请求可以是具有特殊标签的普通HTML,该特殊标签将该普通的HTML标记为支付请求,或该请求可以是具有相关支付信息的新的HTTP状态代码。完成这件事的方法很多。
4.当浏览器程序接收付款请求时,它会弹出询问用户是否愿意支付该金额的窗口(1440)。
5.如果答案是肯定的,那么费用将从用户钱包中扣除,且保证(可能以加密签名包的形式)被发送到网站(1450),通常作为另一个HTTP get,或许带有支付参数。
6.网站检测/接收支付并正常返回页面HTML(1460)。
对于这种情况,它表面上看起来类似于一些其他支付***。大多数其它支付***会止于这种情况,不提供任何额外的功能,或提供上述使用的基础设施,该基础设施不允许实现本发明的进一步的优点。
简单的实例,ISP订户:
大多数消费者其实不会直接用现金支付一个典型的交易。没有人愿意来处理美分支付;而事实上,没有处理支付美分零钱的合理的方式。通常,大多数消费者会收到捆绑交易,无论是从他们的ISP(互联网服务供应商),还是从其一些其他来源。例如,他们可能有权花费高达$5在购买内容上,作为他们每月ISP费用的一部分。即:
·ISP允许每户每月花费$5,但是很明显地期望平均利用率要低得多(同样地,平均带宽利用率低于最大允许值);以及
·用户的钱包里有$5的积分(本月),但这只是来源于ISP给的积分,而不是实际现金。
实施这种***的详细步骤如下,如图15所示:
1.如前文所述,搜索引擎将用户指向网站(1510)。
2.如前文所述,用户点击链接,这意味着他们的浏览器确实执行HTTPget(1520)。
3.如前文所述,网站返回支付请求,比如说该页面收费1美分(1530);
4.如前文所述,当浏览器程序接收到付款请求时,它会弹出询问用户是否愿意支付该金额的窗口(1540)。
5.这个版本的新的内容。如果用户的答案为“是”,那么浏览器确认ISP愿意担保该该笔支付,并且将该担保转发到网站(1550)。有很多方法可以做到这一点,最简单的方法是只转发支付请求到ISP并接收担保,该担保随后会被转发到网站。基本上,该网站从ISP接收支付,发送内容给用户。
6.网站检测/接收支付并正常返回页面HTML(1560)。
这个版本超出了竞争对手所能做的范畴。
简单的实例,专业性:
对于许多领域,有专业协会和其他想要将要“整合”信息内容的实体。例如,CPA(注册专业会计师)在美国的会计专业处于顶端。AICPA(美国会计师协会)开展专业协会的正常活动,包括将关于会计相关的新闻通给成员。AICPA会提供访问专业网页内容的成员福利,该专业网页内容包括一定数量的期刊、报纸等。AICPA会给每个成员一个积分,这很像ISP提供给用户的积分。
很多消费者会从他们的ISP以及一个或多个专业/专门协会中获得积分。这使得该过程有点复杂。如图16所示:
1.如前所述,搜索引擎将用户指向网站(1610)。
2.如前所述,用户点击链接意味着浏览器执行HTTP get(1620)。
3.这个版本新的内容,网站返回支付请求(1630),比如说该页面收费1美分。该请求也将包含具有特殊交易的协会的列表和每笔交易的明细。这笔交易对于协会成员来说是免费无限制访问的,或每个页面半价等。
4.这个版本的新的内容,当浏览器程序收到支付请求时,它为钱包匹配不同的交易并且确定哪笔交易是适用的。浏览器然后就会弹出询问用户选择期望交易的窗口,或确认支付那笔金额的意愿(1640)。
5.这个版本的新的内容。在用户选择该笔交易后,浏览器确认ISP/协会是否愿意保证该该笔支付,并且将该保证转发到网站(1650)。
6.网站检测/接收支付并正常返回页面HTML(1660)。
此版本远远超出竞争对手能做到。
多币种:
生成所有路径后,评估每条路径,在给定的路径中的每个节点接收到用于处理交易的“费用”。每个节点的费用是由节点指定的-这就像维萨(Visa)和万事达***(MasterCard)都能指定他们处理一次***支付要收取多少费用。付款请求包含接收者想要的金额,***向后工作确定付款人实际上必须要支付多少。可行路径提供给用户以供选择,允许用户选择期望的路径,或者也许设置默认选择最便宜的路径。它是由每个节点来决定它的费用;但是,如果它的费用很高,那么用户就不会选择包含它的任何路径。这鼓励价格竞争。
可以有多种货币和不同套餐的交易。例如,一个付款请求可以说:
·15美分,必须通过子PA-US结算
·或100日元JPY,必须通过子PA-JP结算
·或10,000英里,必须通过子PA-美国航空公司结算
·或来自AICPA的2个积分,必须通过子PA-AICPA结算
注意,各种货币、信誉积分,菲亚特将显现给客户,如果客户有办法以这些形式支付。例如,客户可能仅仅有美国银行账户和加拿大货币,那么她将仅被提供使用这两种货币的支付选项。
付款人将会查询她是否能得到2个AICPA积分,并且总费用以美元形式表征作为付款人需要支付的(包括所有交易费用和货币兑换)。然后,付款人/用户可以选择哪条路径-是否选择使用AICPA积分可能取决于用户在将来想要一些AICPA的独家内容或也许是在月底并且她明天将得到一些更多的AICPA积分。由于货币被指定在路径的每个步骤中,关于货币没有混淆。
广告实例:
如上所述,广告可以被***到由不同的实体进行的交易中。例如:
·内容供应商能够将价格指定为“免费广告”代替收取费用。
·付款人子PA-AICPA可以***广告。例如,美国宝马可能要推出针对CPA的广告(大概像宝马这样的高档轿车的可能买家),但不会仅仅是任何CPA;该公司可能希望将目标定为寻找关于汽车评论的信息的CPA。目前,没有一点方法来做到这些。用本发明的***,美国宝马可能与AICPA联系,使得当子-PA-AICPA“看到”关于“对口”文章的交易时,免费计算净成本(或甚至特别报价)。该特别报价甚至可以由隶属度和其他信息进行调节。对于新CPA的特别报价可能是针对宝马3系,而对于很长一段时间的成员(或高级成员)特别报价将针对宝马7系。该可能性是无止境的。
·几乎任何其他实体也能够***广告,唯一的限制是实体所知道的。需要注意的是实体可以积累信息。例如,子PA-ISP可能会发现读者在某学科特别感兴趣,并相应地***广告。
·这(可能地)允许ISP(和其他积分提供者)建立全面的用户资料。该资料比源于会员卡等的资料更全面,这对于数据整合商进入这个市场将足够有吸引力。
具体实施例:
作为具体的实例,该消息序列可能以如下方式进行处理(参见图17):
1.用户请求来自供应商的信息(1705)
A.经由HTTP的一些诸如“获取物品-URL”等的信息
b.“物品-URL”识别购买的确切物品。
C.值得提醒的是,HTTP指定返回IP,所需的语言[S],所需的格式[S]以及其他信息。
2.供应商发回报价(1710)
·在正常的网络使用情况下,“HTTP get”请求将得到状态码200-意味着完成。有时,是状态码401-意味着未授权(与WWW-验证标头字段一起),然后用户应重试以请求必要的验证。
·HTTP实际上有状态码402-保留付款需求。我们可以使用402(其需要更新标准),或者使用401(和定义我们自己的关于如何构建WWW-验证标头字段的约定)。
·在任一情况下,报价将包括:
不同货币的价格列表。请注意,每种货币的价格可能会完全不同-事实上,一些货币(比如航空公司飞行奖励积分)可能不能转换为其他货币。有些价格可能很奇怪-“免费,但必须是会员”或其他东西。
为供应商所知的付款人列表,包括由这些付款人(及其PA)处理的货币。
3.用户访问路径查找器查找路径(1715)。这个步骤的目的是寻找随着用户开始而随着供应商结束的PA链和/或结算所。
·用户接收支付请求(更严格地说,浏览器程序接收用户的行为请求)
·用户将具有一个带有他们付款人(可能是用户的ISP、专业协会,整合像火车模型的专业整合者)的列表的“钱包”,也包括由每个付款人处理的货币。
·将付款人+货币的两份列表都发送到路径查找器[连同用户ID以及用户-付款人想要任何的信息)[这假设路径查找器功能通过付款人执行;如果其他实体允许,可以相应地调整]
4.路径查找器发回可行路径(1720)。
·在每个用户付款人和每个供应商付款人之间查找(或建造)的所有可能路径
·每个可能路径必须包括必要的货币兑换
·每个路径中的每个组件必须包括由该组件收取的“手续费”。理想地,手续费应表示为“+0.2美分”和/或“+4%”,但没什么阻止更复杂的语言,我们很可能仅仅以上述两种形式开始加上编码URL。编码URL旨在做类似这样的事情,注册并返回表示成功与否的返回码。编码URL也应该有它做什么的文字描述,例如,将显示“如果您注册,那么就免费”而作为这条路径的费用。当用户选择这条路径,调用编码URL来为用户注册。在编码URL返回一个神奇的讯标之后,该讯标被传递到供应商作为注册的证据。
·每条可能的路径应被(加密地)签署-我们只关心完整性和认证,所以我们只需要将它签署,也没有必要去加密。
·优选地,可以预计算和预签署该路径(为了简单和速度起见,我们可能要将路径分成几个签署的片段-从付款人到CH、从CH到CH、从CH到付款人)。这减少了CPU进行路径查找的时间,但意味着实际费用计算必须由用户来完成。
·对于第三方广告等可能***附加路径
·将可能路径列表发送返回用户
5.用户计算每条路径的费用(1725)
·用户得到可能路径的列表后(无论是从路径查找器还是从结算所处获得),他们可以查看每条路径来预计“实际成本”和可能的广告交易。
·路径为类似这样的内容:用户→付款人-威瑞森(Verizon)→PA-花旗银行→CH-美国→CH-加拿大->PA-皇家银行→付款人-RB-温哥华→供应商。在本例中,用户是依靠她的ISP(威瑞森(Verizon)),威瑞森(Verizon)通过花旗银行路由所有款项,其接下来通过国家结算所结算,最终进入处理供应商的支付款项的皇家银行的温哥华分行。
·在每条路径,路径中每家实体进行分配流入货币和流出货币。也就是说,路径查找器可决定谁来做谁兑换;这意味着每家实体必须指定给路径查找器用于货币兑换的兑换费(包括兑换率,这应该由每家实体定期更新)以及路径查找器将选择最低的总费用。此功能必须保持可能的路径低于到可管理的水平-否则路径数目可能随着涉及的货币数目成倍增长)。
·另外,货币兑换并不是路径的一部分。每个组件指定它将执行兑换的兑换率。然后,用户浏览器也将负责选择货币兑换。这进一步降低了路径查找器的工作,但是增加了浏览器的工作。
·每家实体也必须公布其处理该笔交易的费用。费用可以是固定费用,比如说1/2美分美元,或百分比,比如说10%。在某些情况下(促销、广告等),可能是-100%,其意味着用户什么都不用支付,而是广告客户支付所有的费用给供应商;或它甚至可能是-100%-5美分,这不仅意味着它是免费给用户的,用户实际上获得支付的5美分!
·用户(实际上是浏览器/插件)通过以供应商为开始,以期望的价格为结束的方式计算路径的费用,逐跳地检查路径。在每跳处,紧跟着实体公布的费用(货币转换率应已经包括在路径中)。
·一些路径可能是“滑稽”的,因为用户被支付钱(见上文)或可能是免费的,但需要签署一个邮件列表或诸如此类。
6.用户选择使用哪个路径(1730)
·将选择呈现给用户-这是为了让用户选择哪条路径(隐式地选择货币和付款人),并确认该交易应该进行。
·这能通过弹出窗口实现,或它将通过这样的预配置设置来控制,该设置比如“所有***的价格低于5美分才能进行”、“从ISP套餐包1美分以下的请求可以进行”等。
·这可以是非常简单的或复杂的,并且完全是在浏览器程序的控制下。所以新用户不必了解复杂性,而标准用户则可以拥有所有的控件。
7.用户要求付款人证明这笔支付(1735)
·用户选择路径后,用户必须向她的付款人发送请求以证明此笔支付。
·请求将包括该物品-URL、路径和用户ID(或付款人需要对用户进行验证的任何内容)。其确认买的是什么、谁买的、谁将支付、资金如何转移。
8.付款人将支付证书发送给用户(1740)
·付款人执行它自己的业务逻辑来决定是否授权用户花这个钱,等等。如果是这样,付款人签署具有上述信息的交易-这种行为证明付款人把金额支付给链中下一个链接。(如果付款人支付失败,PA向上的层次结构负责到大的结算所)
9.用户将付款证书发送给供应商(1745)
·收到签署的交易后,只是将它发送给供应商作为新HTTP获取请求的一部分。
10.供应商核实支付证书(1750)
·供应商收到签署的付款证书并检查
ο付款人的签名
ο付款人的证书尚未到期。
ο为了保证付款,我们可能想在付款人证书上有很多限制-到期时间短、每笔交易限额小以及限制每个供应商每天总交易的组合。这限制了由流氓PA造成的损失,因为PA在父级PA行动之前仅仅能够以有限的金额欺诈每个供应商。
ο可替代的安全检查类似有:
■散列支付凭证(这是为了确保整个证书有助于散列键)
■一定比例的散列值(比如说被10整除的所有散列值)意味着支付证书应与父级PA进行确认(这可能是由父级PA签署的付款人证书的一部分)。父级PA可以自由地使用任何业务逻辑来决定付款人是否“变成流氓”。对于大额的交易,一些供应商可能会决定核实较高的比例。
■作为变型,有可能需要付款人检查散列值,并访问它的父级PA签署该支付证书。这使得用户更简单。
■这具有的优点是,只有不良付款人需要被供应商追溯,并且可以通过改变采样率调整损失极限。假设平均交易为1美分,然后0.001的采样率意味着平均每家供应商将仅仅损失$10。或0.01的采样率意味着平均最大可能损失为$1。
11.另外,供应商将支付证书传递给供应商付款人,并且该供应商付款人做所有这些检查(在图17中未示出)。其优点,无论如何,付款证书必须传递给供应商付款人,所以还不如做检查-尤其是由于它负责收集。
12.供应商将期望的物品发给用户(1755)。此时,供应商应该高兴,因为支付已经得到了保证,并且现在可以做任何需要的处理以提供内容或其他产品给用户。
13.用户付款人沿着路径发送支付到CH(1760)
·在一些约定时间内(每周、每天、实时、诸如此类),支付通过路径中的第一PA(根据定义,由担保支付的PA)进入路径。
·第一PA将签署的交易发送给路径中的第一CH(可能作为一个大批量交易的所有的CH)。
·也应该做其自己的内部账目以为客户做账单(以及它可能是免费的,套餐中的一部分包,或诸如此类)。
14.结算所结算(1765)
·在约定的时间,或当接收足够多的交易,或发生任何触发条件,结算所开始结算交易。
·每个CH的第一步是将交易转发到下一跳CH(在路径中可能有多个CH)
·当每个CH将其所有的交易转发之后,每个CH具有包括它的每笔交易。
·每个CH现在能够计算该如何将钱在它和它的同行之间转移(以及将钱往哪个方向转移)。
·每个CH与其同行通信以确认每个都同意。
·如果存在分歧,这两个CH的交易可以比较交易清单。由于签署了交易,这种事情应该很容易解决。
·如果得到证实,那么资金在CH之间流动。
·路径中的第一个CH和最后一个CH为他们的PA和子PA计算资金(在两个方向上)
·净额移动
15.接收器应该有正确的金额(1770)
·接收器应该接收正确的金额。
·CH或PA应该能够提供已结算的交易列表。
·接收器应能使自己的列表与提供的列表相统一。
这样一来,该过程是完整的,并且所有方都满意。
典型的性能统计信息:
一些示例性技术措施如下:
·2009年,在2.2GHz的AMD皓龙处理器8354上,2048比特RSA签署用了6毫秒(参见http://www.cryptopp.com/benchmarks.html)。我们可以安全地假设在2013处理器上,一个签署将会用单个毫秒。需要注意的是核实签署费用较少的工作-假设每家实体将进行签署是非常保守的估计。
·对于亚马逊(Amazon)EC2,一个“高CPU预留实例”,对于以每0.01美分每秒工作的“特大型”(用于美国东部数据中心)是每小时36美分。这意味着RSA签署费用10微美分。这意味着我们能够按100倍的速度过量地配置CPU,并且每个签署仍然仅仅花费我们1毫美分。
·Ec2带宽为每GB2美分左右(不同的计划和数据中心的平均值)。假设每笔交易将占用2K字节:
ο1000个字节的URL用来识别正被购买的确切物品。
ο100个字节用于每家实体寻址和支付详情。
ο在交易中有10家实体
·然后,在单个GB中,费用为500K的交易,或每路每笔交易4微美分
·因此,处理单笔交易的费用对于在链中的每家实体来说是低于20微美分。所有实体总费用远低于1/2毫美分。
·EC2存储每月每GB约25美分。每笔交易是2KB,因此每月每笔交易将花费12微美分,或每年每笔交易将花费0.3毫美分。除此之外,归档存储应该更便宜。
·因此,假设所有十家实体都要存储交易,我们正在寻找全***范围内的总费用在远低于5毫美分的情况下处理所有交易并且存储一年(在10个位置!)。
对于付款人门户网站,一个EC2实例每小时可处理360万个请求(60分*60秒*1000毫秒),并且对于比如说一百万规模的用户群来说是足够的-这取决于有多少用户是在线并且在任何时候都是活跃的。当然,单个CPU实例在小到中型的ISP上应该足够的。由于软件很容易并行化,更多的CPU实例可以根据需要被打开。
优点:
与现有***相比,本发明的***和方法具有许多优点。例如:
1.***是“整合的消费者”,在这个意义上,消费者知道付给谁钱,以及付多少钱。这是支付的单个点,与分别支付每个供应商截然相反。这是***有效操作的先决条件,并且是用户友好性的先决条件。换句话说,我愿意这个月支付$4.23,但我不愿意支付上百个一两美分的账单。
ο用户可以以净账单的形式支付帐子PA(类似***账单)
ο用户还可以从ISP或其他协会获取积分,可能是捆绑的一部分;
2.***是“整合的供应商”,在这个意义上,供应商知道向谁收费,以及收费多少。出于上述同样的原因,支付的单个点是必要的。该网站并不想收美分,相反,该网站希望别人收取所有的美分,然后仅给网站一张支票就行。通过整合,消费者的成本显著下降,即使对那些需要将货币输入***的人;
3.***具有查账索引功能。即使交易很微小,总款项必须能够分解到每笔交易,并且每笔交易必须具有完整的追溯性以验证每个付款人/付款人。这很容易与所述的***兼容;
4.***是不匿名的。尽管该***针对微小的交易,并不限制交易的规模或数量;所以累计的规模可能是巨大的。这意味着有洗钱的可能,因此每笔交易必须溯源到付款人和收款人。这对于进入支付***的许多研究人员来说可能是“格格不入”的,但我们一定要避免大的法律雷区。由于所有支付都是通过PA/子PA来完成,我们能够将付款人和收款人识别到子PA。然后由子PA来满足当地的法律、习俗和商业惯例。
5.由于交易通常会先发生,然后资金随后转移(几小时或几天的时间之后),我们保证这些钱会转移。同样,每单笔交易可能很小,但总量会很大。由每个PA为其子PA进行担保。这可能转化为发布履约保证金的PA和子PA,以及转变成在每笔交易的可追溯性和/或授权方面的更复杂的设计。
6.通过本***的设计,在各个层面都鼓励竞争(除了在结算所的层面上)并且竞争不只是有竞争对手,而且每笔交易都是小型竞争性招标选择过程。
7.每个用户的钱包中都可能有不同的积分-一种来自ISP,一种用于普通新闻,一种用于专业兴趣,一种用于爱好,等等。本***可以很容易的处理许多积分并能充分利用各个积分的不同属性。具有将货币输入到***的灵活和可替代方式允许用户利用信誉度货币以及运营商代扣;
8.通过利用和修改传统的零售模式,连同***模式和认证中心模式,我们已经想出了效果良好的、扩展到全球范围内布局的、并且符合所有要求的独特的设计方案;
9.布局和市场接受度可能是渐进的。每个辖区可以决定是否想要竞争-如果想的话,就允许多个PA。如果不想的话,就允许单个PA。它可以加入它想要的结算公司。没有必要同时使全世界转变;
10.如上述所指出,“4大”公司也是阻性的:它们都需要几次点击来执行购买。与此相反,用本发明的***,您将与供应商预先达成协议,这允许您即时访问内容或虚拟商品,因为您已经预先支付或者有某种形式的积分允许您这样做;
11.真正的全球化:我们提出的解决方案将几乎允许任何人,在任何地方,有能力用他们可用的货币(包括信誉度货币和法定货币)购买内容或虚拟物品,而不管他们地理位置在哪;
12.固有的竞卖功能:因为他们为实现交易而竞争,所以在我们的支付生态***中为合作伙伴创建更多的机会;
13.更好地控制广告内容:我们的***将允许客户更好地定制广告和收入;
14.通过我们正在申请专利的自动化层次结构统计限制设置技术更好地防范了欺诈行为:当今大多数解决方案是售后服务,即,在欺诈问题已经发生之后,再处理欺诈问题,而我们打算采取更精细地在前防范,甚至在出售发生之前就进行;
15.较大的生态***:本发明的***重点是为购买全球内容和虚拟商品提供全球性的***。这一重点将为:1)提供更多的供应商合作伙伴以及2)金融合作伙伴,他们将在该生态***中获益;
结论:
本发明已经描述了一个或多个相关的实施例。然而,对于本领域技术人员将显而易见的是,在不脱离如权利要求书所定义的本发明的范围的前提下,可以作出一些变化和修改。
本发明的方法步骤可以以存储于各种格式(诸如目标代码或源代码)的可执行机器代码集的形式体现。这样的代码通常可以被描述为程序代码、软件,或简化的计算机程序。显然,可执行的机器代码或代码的部分可以与其他程序代码集成,作为子程序、插件,附件、软件代理,通过外部程序调用以本领域中已知的固化软件或者通过其它技术来实现。
本发明的实施例可以通过计算机处理器或类似的编程设备以方法步骤的方式来执行,或者可通过配置有执行这些步骤的装置的电子***来执行。同样地,电子存储介质,例如计算机软盘、硬盘驱动器、拇指驱动器、只读光盘存储器、随机存取存储器(RAM)、只读存储器(ROM)或本领域已知的类似的计算机软件的存储介质,可以被编程以执行这样的方法步骤。同样地,表示这些方法步骤的电子信号也可以经由通信网络传送。
所有的引证都通过引用的方式并入本文。

Claims (28)

1.一种在付款人和收款人之间进行电子支付的方法,包括:
通过付款机生成安全电子交易,所述安全电子交易包括一个证书,该证书具有设定交易规则的扩展;
通过网络实体的付款路径将所述安全电子交易从所述付款机路由到收款机,所述网络实体中的特定个体将各自的证书添加到所述安全电子交易,每个所述各自添加的证书具有设定交易规则的扩展;
并且在所述收款机处接收所述安全电子交易,包括接收来自支付路径中每个所述网络实体的证书。
2.如权利要求1所述的方法,其中所述支付路径是所选择的支付路径。
3.如权利要求1或2中任一项所述的方法,其中将各自的证书添加到安全电子交易的所述网络实体中的每一特定个体,包括在选择的支付路径层次结构中独立层上的网络实体。
4.如权利要求1~3中任一项所述的方法,其中执行生成和路由的步骤以响应接收到的电子支付的请求。
5.如权利要求1~4中任一项所述的方法,确定与客户相关的所述付款人和与供应商相关的所述收款人之间的可用支付路径,每一所述可用支付路径具有层次结构;对所述客户从所述可用支付路径中选择一条路径进行响应,通过所选择的支付路径路由所述安全电子交易,所述安全电子交易从所选择路径的给定层次结构层中的每一实体处接收证书,每个所述证书包括一个设定交易规则的扩展。
6.如权利要求5所述的方法,还包括计算和通知所述付款人每个所述可用付款路径的费用。
7.如权利要求1~6中任一项所述的方法,还包括供应商,该供应商对接收的已签发的支付证书中预定部分进行检查。
8.如权利要求1~6中任一项所述的方法,其中支付证书通过在给定的时间段内允许预定数目的交易的方式而影响订购管理协议。
9.如权利要求1~6中任一项所述的方法,其中支付证书通过在给定的时间段内允许预定金额交易的方式而影响订购管理协议。
10.如权利要求1~6中任一项所述的方法,其中通过限定所述付款人与所述收款人之间累计交易金额来防范欺诈行为。
11.如权利要求1~6中任一项所述的方法,其中通过限定所述付款人与所述收款人之间累计交易的数量来防范欺诈行为。
12.如权利要求1~6中任一项所述的方法,还包括通过保持交易的可追溯性来防范洗钱,以及通过限定所述付款人与所述收款人之间累计交易的数量和金额来防范欺诈行为。
13.如权利要求1~4中任一项所述的方法,还包括:
在与所述付款人相关的消费者和与所述收款人相关的产品供应商之间建立实体的层次结构;
每个实体以递归的方式通过所述层次结构确定从所述消费者到所述产品供应商的可用支付路径:识别所述层次结构中的每个相邻实体;以及将每个相邻实体报告给所述每个相邻实体各自的父级实体;
整理所述消费者处接收的相邻实体数据,以确定可用支付路径;
和经由所述可用支付路径中所选择的一条路径执行所述消费者和所述产品供应商之间的电子支付。
14.如权利要求1~4中任一项所述的方法,还包括以下步骤:
在与所述付款人相关的消费者和与所述收款人相关的产品供应商之间建立实体的层次结构;
以递归的方式通过实体的层次结构确定从所述消费者到所述产品供应商的可用支付路径和交易费用:识别所述层次结构中的每个相邻实体;请求每个相邻实体识别与它们相邻的实体,以及每笔交易费用;并且将这些相邻实体中的每个实体和交易费用报告给所述父级实体;
整理在所述消费者处接收的相邻实体和交易费用数据,以确定可用支付路径和每个路径的交易费用;
选择所述可用支付路径中的一条路径;并且
经由所述可用支付路径中所选择的一条路径执行所述消费者和所述产品供应商之间的电子支付。
15.如权利要求1~4中任一项所述的方法,其中所述付款人与付款机相关联,所述收款人与收款机相关联,所述方法还包括:
通过所述付款机生成安全电子交易,所述安全电子交易包括一个证书,该证书具有设定交易规则的扩展的;
通过网络实体的付款路径将所述安全电子交易从所述付款机路由到收款机,通过如下方法确定所述付款路径:以递归的方式请求所述层次结构中的相邻实体将它们各自的相邻实体报告给它们各自的父级;和整理接收到的邻接数据以确定可用支付路径;
以及经由所述可用支付路径中所选择的一条路径路由所述安全电子交易;
并且在所述付款机处接收所述安全电子交易。
16.如权利要求1~4中任一项所述的方法,还包括:
在与所述付款人相关的消费者和与所述收款人相关的产品供应商之间建立实体的层次结构;
通过所述层次结构确定从所述消费者到所述产品供应商的可用支付路径;
计算每条所述可用支付路径的费用;
并且经由所述可用支付路径中所选择的一条路径执行所述消费者和所述产品供应商之间的电子支付。
17.如权利要求16所述的方法,其中选择所述可用支付路径中的一条路径包括消费者选择所述可用支付路径中的一条路径。
18.如权利要求16所述的方法,其中选择所述可用支付路径中的一条路径包括通过默认程序选择所述可用支付路径中的一条路径。
19.如权利要求13~18中任一项所述的方法,其中货币兑换受所述可用支付路径中的所述实体的影响。
20.如权利要求13~18中任一项所述的方法,其中货币兑换受消费者设备上的浏览器的影响。
21.如权利要求16~18中任一项所述的方法,其中所述层次结构中用于给定实体的费用由货币性费用、许可、信誉度积分和虚拟货币组成。
22.如权利要求16~18中任一项所述的方法,其中所述层次结构中用于给定实体的费用还包括关于内容使用的条件。
23.如权利要求16~18中任一项所述的方法,其中所述层次结构中用于给定实体的费用包括要求客户浏览广告,而不是要求向客户收取货币形式的费用。
24.如权利要求16~18中任一项所述的方法,其中所述层次结构中用于给定实体的费用包括要求消费者浏览由第三方提供的广告。
25.如权利要求16~18中任一项所述的方法,其中确定可用支付路径和计算所述费用的过程包括:
定期确定可用支付路径并且计算所述费用,独立于任何特定请求进行交易;
以及缓存所述可用支付路径和计算得到的它们各自的费用。
26.如权利要求25所述的方法,其中按天执行确定可用支付路径和计算所述费用的过程。
27.如权利要求25所述的方法,其中确定可用支付路径包括使用路径搜索门户网站确定可用支付路径。
28.一种用于在付款人和收款人之间进行电子支付的***,包括:
付款机;
收款机;
及将所述付款机和所述收款机互相连接的网络;
所述付款机***作用于:
生成安全电子交易,所述安全电子交易包括一个证书,该证书具有设定交易规则的扩展的;
以及通过所述网络实体的付款路径将所述安全电子交易从所述付款机路由到收款机,通过网络,所述网络实体中的特定个体将各自的证书添加到所述安全电子交易,每个各自添加的所述证书具有设定交易规则的扩展;
以及所述收款机可***作用来接收所述安全电子交易,包括在所述支付路径中所述网络实体中的特定个体的证书。
CN201480064068.4A 2013-10-25 2014-10-24 用于对网页内容、虚拟商品和小额物品付费的方法和装置 Pending CN105960654A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CA 2830855 CA2830855A1 (en) 2013-10-25 2013-10-25 A design for micro-payment system for web contents
CA2,830,855 2013-10-25
PCT/CA2014/000758 WO2015058282A1 (en) 2013-10-25 2014-10-24 Method and apparatus for paying for web content, virtual goods and goods of small value

Publications (1)

Publication Number Publication Date
CN105960654A true CN105960654A (zh) 2016-09-21

Family

ID=52992076

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480064068.4A Pending CN105960654A (zh) 2013-10-25 2014-10-24 用于对网页内容、虚拟商品和小额物品付费的方法和装置

Country Status (5)

Country Link
US (1) US20160267478A1 (zh)
EP (1) EP3061053A4 (zh)
CN (1) CN105960654A (zh)
CA (2) CA2830855A1 (zh)
WO (1) WO2015058282A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018188568A1 (zh) * 2017-04-11 2018-10-18 杭州呯嘭智能技术有限公司 动态网络衡算的深度支付分账方法及***
CN110322234A (zh) * 2018-03-28 2019-10-11 武汉斗鱼网络科技有限公司 一种充值方法、装置、服务器及介质
CN112488691A (zh) * 2020-11-30 2021-03-12 乐刷科技有限公司 商户结算计费方法、装置及计算机可读存储介质

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9911119B2 (en) * 2015-02-25 2018-03-06 Ebay Inc. Multi-currency cart and checkout
US10339523B2 (en) 2015-07-14 2019-07-02 Fmr Llc Point-to-point transaction guidance apparatuses, methods and systems
US10778439B2 (en) 2015-07-14 2020-09-15 Fmr Llc Seed splitting and firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
US10644885B2 (en) 2015-07-14 2020-05-05 Fmr Llc Firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
US11636471B2 (en) 2017-12-15 2023-04-25 Fmr Llc Social data tracking datastructures, apparatuses, methods and systems
US11488147B2 (en) 2015-07-14 2022-11-01 Fmr Llc Computationally efficient transfer processing and auditing apparatuses, methods and systems
US11436598B2 (en) 2017-12-15 2022-09-06 Fmr Llc Social data tracking datastructures, apparatuses, methods and systems
US10504179B1 (en) 2015-12-08 2019-12-10 Fmr Llc Social aggregated fractional equity transaction partitioned acquisition apparatuses, methods and systems
US10992469B2 (en) 2015-07-14 2021-04-27 Fmr Llc Seed splitting and firmware extension for secure cryptocurrency key backup, restore, and transaction signing platform apparatuses, methods and systems
CN106598553B (zh) * 2015-10-14 2021-03-16 斑马智行网络(香港)有限公司 一种信息卡片生成方法、装置及***
CN106875167B (zh) * 2016-08-18 2020-08-04 阿里巴巴集团控股有限公司 电子支付过程中资金交易路径的检测方法和装置
CN109034955A (zh) * 2018-07-03 2018-12-18 泰康保险集团股份有限公司 账单生成方法及装置
CN111311221B (zh) * 2020-02-14 2023-08-22 武汉大学 区块链支付通道网络的支付管理方法
IT202100001142A1 (it) * 2021-02-01 2022-08-01 Francesco Ricci Sistema di parificazione delle condizioni economiche nell’esecuzione di pagamenti elettronici

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083186A1 (en) * 1999-06-22 2002-06-27 Stringer Andrew Mark Computer network payment system
WO2013015746A2 (en) * 2011-07-27 2013-01-31 Goodwin Russel Intelligent payment system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100452072C (zh) 1995-02-13 2009-01-14 英特特拉斯特技术公司 用于管理在第一装置和第二装置之间的数字文档的分布的方法
US5903880A (en) 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
US8620805B2 (en) 2012-03-27 2013-12-31 Citicorp Credit Services, Inc. Methods and systems for processing payments globally over one of a plurality of processing paths

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083186A1 (en) * 1999-06-22 2002-06-27 Stringer Andrew Mark Computer network payment system
WO2013015746A2 (en) * 2011-07-27 2013-01-31 Goodwin Russel Intelligent payment system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018188568A1 (zh) * 2017-04-11 2018-10-18 杭州呯嘭智能技术有限公司 动态网络衡算的深度支付分账方法及***
CN110322234A (zh) * 2018-03-28 2019-10-11 武汉斗鱼网络科技有限公司 一种充值方法、装置、服务器及介质
CN112488691A (zh) * 2020-11-30 2021-03-12 乐刷科技有限公司 商户结算计费方法、装置及计算机可读存储介质
CN112488691B (zh) * 2020-11-30 2024-05-07 乐刷科技有限公司 商户结算计费方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
WO2015058282A1 (en) 2015-04-30
EP3061053A4 (en) 2017-06-28
CA2928484A1 (en) 2015-04-30
EP3061053A1 (en) 2016-08-31
US20160267478A1 (en) 2016-09-15
CA2830855A1 (en) 2015-04-25
WO2015058282A8 (en) 2015-05-28

Similar Documents

Publication Publication Date Title
CN105960654A (zh) 用于对网页内容、虚拟商品和小额物品付费的方法和装置
RU2491634C2 (ru) Расчетный центр виртуальных очков
US9785988B2 (en) In-application commerce system and method with fraud prevention, management and control
Pousttchi A modeling approach and reference models for the analysis of mobile payment use cases
US20130179337A1 (en) Account free possession and transfer of electronic money
US20010054006A1 (en) Points trading service method and system therefor
WO2014108910A2 (en) Products &amp; services card and global card or payments network(s) mediated e-commerce &amp; marketing service(s)
KR102094101B1 (ko) 연동형 디지털화폐 시스템 및 그 방법, 전용 디지털화폐와 연동되는 전자지갑 간 결제 시스템 및 그 방법
CN104732418A (zh) 积分交易的***及其方法
Turban et al. Electronic commerce payment systems
Painuly et al. Mobile Wallet: An upcoming mode of business transactions
US20120303516A1 (en) Donation and payment system
JP7497833B2 (ja) 法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム
JP2002140642A (ja) 点数制度に基づくポイントを変換する方法、装置および記録媒体
JP2019139297A (ja) プログラム、情報処理装置、情報処理方法及び製造方法
WO2020118457A1 (en) Server arrangement and related methods for performing financial operations
KR20130106165A (ko) 일체형 마켓플레이스에서 상품들의 통합 결제를 위한 인터페이스를 제공하는 광고 제공 시스템 및 방법
KR20200109463A (ko) 키오스크 기반 복합 서비스 제공 방법
JP2002032687A (ja) 定額電子クレジットカードシステム
US20200334711A1 (en) Online E Commerce and Networking System with an Instant Payment and Settlement Digital Currency Application for Realizing Internet of Values
JP2002099852A (ja) 決済方法および決済システム
JP2013101590A (ja) コンテンツ販売システム、及び、その方法
KR20130012229A (ko) 광고주와 사용자간의 거래에 대해 추가 적립률의 적립금을 제공하는 적립금 관리 시스템 및 방법
KR102472450B1 (ko) 전자지갑을 이용한 결제대금 즉시 정산 서비스 제공 시스템
KR100503017B1 (ko) 서버가 제휴 사이트 및 오프라인 상점에서 전자 상거래를수행하는 방법 및 시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20160921

WD01 Invention patent application deemed withdrawn after publication