专利名称：鉴权支付的制作方法
相关申请本申请要求Greg Whitehead、Michael Graves和Thane Plambeck于2000年4月17日提交的题为“鉴权支付”(”AuthenticatedPayment”)的、序列号60/198,110的美国临时专利申请的优先权利益，该主题在此引入作为参考。
发明
背景技术：
领域本发明涉及在在线商务交易中对购买者进行鉴权，并且更具体而言，涉及到使一种分离的鉴权服务对购买者进行鉴权。
背景技术：
随着因特网和其他形式的网络通信正受到越来越多的欢迎和认可，在线商务成为很大的业务。比如，消费者购买、商家到商家的商务和证券交易以及发生在因特网和/或无线网上的其他形式的投资的量正稳定地增长，其他形式的在线商务也是如此。另外，人们正努力开发可替代的商业模型(如拍卖和组合购买)和可替代形式的支付(如电子现金和基金的因特网授权发送)以试图利用在线商务的独有特征。
然而，在线商务的其中一个缺点是购买者鉴权有困难。比如，考虑消费者愿意用信用卡来购买物品的情况。如果购买者是在现实世界中购买，会要求他提供其实际的信用卡(也许上面还有照片)并且他必须在信用卡单据上签名，该签名要与该信用卡上的签名匹配。这些动作可达到两个重要的目的。第一，它们可有一定的把握来确定该购买者被授权使用该信用卡。第二，它们产生了一个记录，使购买者以后很难否认他授权了这次购买。这些因素合起来大大降低了欺骗性交易的风险。
在此交易的在线版本中，对应于提供实际信用卡并签署该信用卡单据的动作并不存在，或者如果存在的话，在降低风险方面并不十分有效。比如，在很多情况下，只要求购买者输入其信用卡号然后点击“购买”按钮。这两个动作比现实世界中更容易是欺骗性的，因为出售者并不知道进行这些动作的人实际上是否获得了使用该信用卡的授权。换言之，出售者很难鉴权购买者。此外，即使真实的信用卡拥有者确实授权了该交易，但日益增加的欺骗风险意味着由于信用卡拥有者可宣称有冒名顶替者授权了此交易而使产生的记录不那么有力。“卡不存在”情况下的额外欺骗风险导致在因特网和其他在线商务系统中处理的交易的交换速率和费用较高，它也许是因特网商务成本基础的最大的单个贡献者。
因特网和其他在线欺骗越来越多的一个原因是在某种意义上个人支付工具信息如信用卡号、支票帐号和相关数据基本已成为“公共信息”，即此数据很容易获得。比如，每次交易中用户都将其信用卡号、终止日期等以未受保护的格式给了每个在线商家。另外，如姓名、地址、社会安全号等信息也可从持卡人之外的来源获得。比如，可搜索的、网上可访问的电话目录和其他类型的目录也包含了很多这种信息。支付工具信息重复而未受保护的公开，加上很多这类信息也可从其他来源获得，这就增加了欺骗性交易的风险。比如，在很多在线交易环境下黑客为了冒充实际持卡人，经常只需要获得信用卡号码和其相联系的姓名和地址信息的数据库。
传统上，购买者鉴权问题已通过使用密码来解决，这种方法在因特网(万维网)商业环境中被普遍地采用，这里购买者典型地使用简单的用户姓名和密码来鉴权自己。如前所述，密码在用作这个目的时有着固有的缺陷，而目前的实现方案进一步加重了这些缺陷。比如，消费者典型地必须用在线过程单独在每个商家注册。结果，因为在线注册的定时经常不允许商家进行很多核查，因此商家核查消费者注册的机会很有限，而且即便有机会核查，其花费也会因为每个商家必须承担自己核查的花费而变得相当高。另外，消费者经常对多个帐户使用相同的用户名和密码。这增加了用户名和密码被泄露的机会，而如果真被泄露，就增加了遭受更大损失的危险。此外，因为用户名和密码典型地都是以明文的形式发送给商家，故不道德的商家也能用此信息来泄露消费者的其他帐户。最后一个例子是，很多当前的鉴权系统的目标是对消费者的身份的鉴权(如证明该用户实际就是某约翰)，但鉴权某人的身份不一定要与核查某人是否获得授权来使用特定支付工具一样。
安全电子交易(即SET)协议是一个为了便于通过因特网的安全支付卡交易而力图解决购买者鉴权问题的协议。在SET中，使用数字证书来创建整个交易中的信用链。比如，消费者有呈送给商家的数字证书。商家有呈送给消费者的数字证书。为了确定可信赖度，双方都核查对方的数字证书和数字证书的底层链。然而，这种方法对于用户、商家和对应的交易处理设施都增加了相当可观的管理和操作复杂度。比如，为了参与此协议，购买者和商家都要求有特定技术，并且每次采用新的数字证书就必须升级技术。结果，SBT未得到广泛采用。
因而，在线商务交易中需要基本的购买者鉴权。购买者鉴权的方法还需要足够灵活以便很容易适应不同应用的变化的安全级别并适应于采用的新技术。优选地，此方法也不显著增加已有的交易处理设施的负担，或者不要求对其进行大范围的修改。
发明的公开内容按照本发明，在线商务交易系统(100)包含购买者(110)、出售者(120)和鉴权服务(130)。期望出售者(120)鉴权(204)购买者(110)是否被授权使用支付工具作为与出售者(120)的在线商务交易的一部分。为此，鉴权服务(130)执行下列步骤，所有这些步骤都作为在线商务交易的一部分实时发生。鉴权服务(130)接收(230)请求以证实购买者(110)被授权使用该支付工具。它确定(246)购买者(110)是否可访问特定的保密信息而未将保密信息透露给购买者(120)。访问保密信息会证实使用该支付工具的授权。根据对购买者(110)是否可访问保密信息的确定，鉴权服务(130)发送(250)包含该购买者(120)是否被授权使用该支付工具的响应给该出售者(120)。在本发明的另一方面，鉴权服务(130)也将有关购买者(110)的简档信息应用(260)到在线商务交易并且/或者处理(270)或至少部分处理该支付交易。鉴权服务(130)也可存储(280)使用该支付工具和/或交易的记录。
在优选实施方案(300)中，在线商务交易发生于因特网上。购买者(110)经由万维网浏览器访问因特网，出售者(120)运行由万维网服务器作为宿主的因特网店面，而鉴权服务(130)实现于万维网服务器上。此外，保密信息包含私有密钥。换言之，使用私有密钥创建数字签名会证明签署者被授权使用相应的支付工具。在此实施方案中，鉴权的请求(330)由购买者提交一种表格(400)来触发，这包含识别该鉴权服务(130)的动作属性。对鉴权服务(130)的请求(330)也包含出售者的地址，使得该鉴权服务知道往哪里发送(350)其鉴权过程的结果。为了鉴权出售者(120)，鉴权服务(130)发送(340)询问请求到购买者(110)，请求购买者(110)使用私有密钥来对一些数据数字地签名。鉴权服务(130)使用购买者的响应(342)来确定(346)购买者(110)是否可访问私有密钥并且然后发送(350)该结果给出售者(120)。鉴权服务(130)还可请求该购买者(110)对交易记录进行数字签名，因而创建(380)交易的强有力的记录。
因为使用分离的鉴权服务(130)而非出售者(120)来鉴权购买者(110)，所以本发明特别有优势。结果，出售者(120)未能获得对与购买者的支付工具相联系的保密信息的访问。这就可防止出售者(120)以后重新使用该保密信息来授权欺骗性交易。
此外，鉴权功能集中于鉴权服务(130)中会导致显著的灵活性和规模经济性。多种类型的保密信息都是适合的，它们每种要求不同的技术来实现。将鉴权功能集中于鉴权服务(130)中会允许在多个出售者(120)间共享所需技术的成本。此外，如果保密信息的类型或者相应的购买者鉴权规程改变，则大幅度的改变只会影响鉴权服务(130)，因而使新鉴权技术将能很容易地实现。如果鉴权服务(130)执行其他功能，如添加购买者简档信息到交易中、支付工具的处理、或者进行交易并保存交易记录，就可实现额外的规模经济性，因为鉴权服务(130)对于这些其他功能来说是自然的集中点。
附图简述在下面的说明中更完全地公开了本发明的这些和其他更详细和特定的目的和特性，这里要参考附图，其中
图1是按照本发明的系统的框图；图2是示意了运行图1系统的方法的事件跟踪；图3是示意了运行图1系统的优选实施方案的优选方法的事件跟踪；以及图4-7是示意图3方法的各种屏幕画面和对话框。
优选实施方案详述图1是按照本发明的系统100的框图。系统100包含购买者110、出售者120和鉴权服务130，它们相互通信。可选地，系统100也包含购买者110可访问的鉴权服务的目录140，以及鉴权服务130都可访问的购买者简档的数据库150和交易档案170。可选的支付网关160也可被鉴权服务130访问，尽管在可替代的实施方案中，可以是出售者120，或者鉴权服务130和出售者120 ，可访问该支付网关160。支付网关160简单的可以是管道，通过它将支付交易转发到各个金融机构。本发明可与很多不同类型的支付网关160(或者甚至没有支付网关)一起使用，并不会限制于特定类型的网关技术。
购买者110想把支付工具用作与出售者120的在线商务交易的一部分。比如，在一个应用中，购买者110是消费者、出售者120是因特网店面的商家，而消费者愿意使用他的信用卡从商家购买一些商品、信息或者服务。另一个例子，购买者110是经由无线电话或手持个人数字助理(PDA)连接到出售者120的个人，出售者120是帐单支付的服务，而个人愿意写“因特网支票”来支付他每月的帐单。再一个例子，购买者110是一个公司或者代表公司行动的个人，他向公司的提供者120购买材料或者服务。支付工具的其他例子包含支票帐户路由号码(accountrouting number)、虚拟货币或者电子现金、存于电子钱包中的预付现金值、购物卡和因特网信用量或者赠券。
由这些例子应该清楚，也可能有很多其他应用，而术语“购买者”和“出售者”用作方便的标记，但并不意味着限制这些实体。不要求“购买者110”实际购买东西，也不要求“出售者”实际出售。类似地，“在线商务交易”并不先至于买卖交易。相反，在线商务交易可以是任何交易，只要其中购买者110愿意把支付工具用作交易的一部分，或者更一般地，可以是从购买者110的鉴权中获益的任何交易。未利用支付工具的应用的一个例子是，“购买者”110可以是个人，而“出售者”120可以是购买者持有其保单的保险公司，而“交易”可能是购买者希望改变其受益人。出售者想在允许该购买者访问其帐户前鉴权该购买者的身份。
图2是示意系统100的操作200的事件跟踪。方法200可粗略分为三大部分购买者注册202、购买者授权204和交易记录206。并非所有实现都利用图2示意的所有三个阶段202-206或者所有各个步骤，但在这个例子中包括它们以示意本发明的各个方面。在购买者注册202中，阶段204中使用的保密信息来鉴权该购买者并且在购买者110和鉴权服务130间建立支付工具。优选地，每个支付工具只发生一次购买者注册202。购买者授权204作为在线商务交易的一部分实时发生。在这一阶段，购买者110向鉴权服务130演示对保密信息的访问。如果该访问被成功地演示，则该鉴权服务130就通知出售者120该购买者110已被授权使用该支付工具。在交易记录206阶段，鉴权服务130创建交易记录，而该记录随后可用作特定交易是否发生的证据。
使用分离的鉴权服务130有很多优点。比如，从下面的描述会更明白，成批的购买者鉴权过程204由鉴权服务130执行。鉴权服务130确定购买者110是否已演示了对保密信息的访问和因此是否被授权使用该支付工具。购买者110只最少地涉及而出售者120基本上根本不涉及。将该功能集中于鉴权服务130导致显著的灵活性和规模经济性。比如，从简单PIN号到复杂的数字证书协议的不同类型保密信息都可用来产生对于不同支付工具的不同级别的安全性。典型地，不同类型的保密信息将要求不同的设施以执行购买者鉴权阶段204。将购买者鉴权阶段204集中于鉴权服务130允许在多个购买者120间共享此设施的成本。此外，如果保密信息的类型或者相应的购买者鉴权规程发生改变，则成批的改变只会影响鉴权服务130，因而使得新鉴权技术能很容易地实现。相比而言，以前的方法如SET要求每个出售者120都提供很多必需的设施。这会导致高成本、较慢的初始接受以及切换到新技术的困难，这些最终会导致SET和类似方法失败。
由于出售者并不涉及购买者鉴权204，所以出售者120并未获得对购买者110的保密信息的访问权，因而该方法也是有优势的。这就防止出售者120以后重新使用购买者110的保密信息来授权欺骗性交易。比如，假设保密信息是PIN号。如果出售者120负责购买者鉴权204，则购买者110会向出售者120公开其PIN号，而出售者以后能将其用于欺骗目的。然而，在当前方法中，出售者120只向鉴权服务130公开PIN号而不向出售者120公开。
此外，因为购买者鉴权阶段204集中于鉴权服务130中，可通过使鉴权服务130也执行其他功能来实现附加的规模经济性，如后面将讨论的那样。比如，鉴权服务130可添加其他信息到交易中(如购买者的运送地址)、处理或者部分处理购买者的支付工具和/或进行交易和保存交易记录。
再参考图2，每个虚线框110、120和130代表系统100中的一个组件。实线框代表方法200中的各个步骤。虚线框中实线框的位置表示该步骤一般由那个组件执行。比如，步骤210位于鉴权服务130的虚线框当中。这表示一般由鉴权服务130执行步骤210。一些步骤有两个框，这表示这些步骤在两个组件中都发生。比如，一个组件可发送消息到另一组件。优选地，这些步骤是通过运行于系统100中各个组件上的软件实现的，可能还借助硬件模块。它们也可在硬件和/或固件中实现。
优选地，购买者注册阶段202在实际在线商务交易前发生。在此阶段202，在购买者110和鉴权服务130间建立保密信息。该信息在这种意义上是保密，即理想情况下它只能由购买者(或者购买者110和鉴权服务130共享秘密的情况下的这两者)知道和/或访问。公众或出售者120一般都无法获得该信息。此外，保密信息对应特定支付工具而证明对保密信息的访问将视为被授权使用该支付工具。
所需安全性的类型决定了可使用不同类型的保密信息。保密信息的例子包含PIN号或密码、网络存储的凭证(如用以支持漫游)、“漫游“的数字签名能力、软件凭证如对购买者机器本地的私有密钥、硬件凭证如硬件权标或者智能卡上携带的私有密钥、生物计量凭证以及加密询问响应协议中使用的信息。
在图2的特定例子中，如下建立保密信息。鉴权服务130接收210使鉴权服务能在以后确定该购买者110是否可访问该保密信息的确认信息。然后鉴权服务130存储212与支付工具相联系的该确认信息，比如作为购买者简档数据库150的一部分。在遵循这一模型的一个实施方案中，购买者的保密信息是私有密钥而相应的确认信息是对应的公共密钥。
在替代实施方案中，购买者注册202可以其他方式实现。比如，确认信息也可不存于鉴权服务130中。相反，它可存在其他地方并在需要时由鉴权服务130取回。可替代地，鉴权服务130并不存储不同于保密信息的确认信息，而可简单地存储保密信息自身(如存储密码或者密码的混编)。另一个例子是，购买者注册202可离线发生。比如，购买者110可填一个申请并将其发送到银行。银行证实该申请上的信息、发信用卡给购买者110并发送帐户信息给鉴权服务130。鉴权服务130创建嵌入了保密信息的智能卡并且该智能卡比如经由邮政服务发送给购买者110。注意在这最后一个例子中，购买者注册202利用了信用卡登记过程。购买者注册也可利用其他过程。
保密信息优选地由购买者110产生以便能使其向其他方公开的可能最小。然而，在替代实施方案中，它可由其他方产生和/或共享，比如鉴权服务，特别是在那些方施加的风险认为较低时。
在购买者鉴权阶段204中，购买者110想把支付工具用作与出售者120的在线商务交易的一部分。鉴权服务130作为交易的一部分实时确定购买者110是否被授权这样做。在图2的特定例子中，发生如下事件。购买者110提议220使用该支付工具。比如，购买者110可提议采用信用卡支付购物。
出售者120想知道购买者110是否被授权使用该支付工具，所以他发送230请求给鉴权服务130以证实购买者的授权。取决于支付工具，鉴权服务130的身份不可能立刻就很显然。可以有一个以上鉴权服务；比如，每个信用卡公司可提供其自己的鉴权服务。解决这个问题的一个方法是使用将鉴权服务和支付工具相联系的目录140。在这种情况下，为了确定鉴权服务对于购买者110提出的支付工具来说是否适合，出售者120访问目录140。
在步骤240-246中，鉴权服务130确定购买者110是否可访问保密信息。鉴权服务130发送240“询问请求”到购买者110。该询问请求要求证明购买者可访问该保密信息。比如，若保密信息是密码，则询问请求可要求此密码。若保密信息是私有密钥，则询问请求可要求购买者110用私有密钥对某物进行数字签名。在一个实施方案中，询问请求也可包括在线商务交易的描述并允许购买者拒绝该交易，比如该描述并不符合该购买者的期望的话。等效地，询问请求相反可要求购买者同意该交易。如果购买者110想继续向前移，他就发送242其“询问响应”回鉴权服务130。
鉴权服务130取回244支付工具早先存储的确认信息并使用该确认信息和询问响应来确定该购买者110是否可访问该保密信息。比如，在密钥例子的一个实施方案中，鉴权服务130混编从该询问响应所断定的密码并将其与存为确认信息的混编信息相比较。在私有密钥例子的一个实施方案中，鉴权服务130使用存为确认信息的公共密钥来确定询问响应中的数字签署的消息实际是否被使用相应私有密钥来数字签署。
然后鉴权服务130发送250对出售者的原始请求的响应到出售者120。该响应包含购买者110是否被授权使用支付工具。它也可包含其他信息，如步骤260和270的文字所述。注意，在购买者鉴权204期间，保密信息并不显现给出售者120。
在前进到步骤260和270前，注意，图2示意的鉴权步骤240-250只是实现购买者鉴权阶段204的一种方式。显然还有其他实现。比如，鉴权服务130可从购买者110而非出售者120接收230鉴权请求。另一个例子中，鉴权服务130可能不使用询问请求240和询问响应242。相反，访问过保密信息的证据可被包括作为初始请求230的一部分。另外，如购买者注册阶段202所述，鉴权服务130还可使用除确认信息(步骤244和246)外的方法来确定购买者是否可访问保密信息。
回到图2，在一些实施方案中，鉴权服务130也可将其他购买者简档信息应用260到交易中。比如，出售者120可请求将购买者的运送地址添加到交易中。鉴权服务130会从数据库150获得此信息并将其添加到正在进行的交易中。这个其他信息可在交易中各个点添加并且可涉及与购买者110或出售者120的通信。在运送地址的例子中，可要求购买者110证实地址并且/或者出售者120可用该地址来计算运送费用，该费用反过来会改变交易的美元数量。
类似地，鉴权服务130也可比如经由支付网关160处理270支付交易。一种极端情况下，鉴权服务130可简单地通告250出售者120购买者110被授权使用支付工具，但出售者120执行要求的所有其他步骤来处理该支付工具。另一种极端情况下，可由鉴权服务130执行步骤来处理该支付交易。在中间情况下，鉴权服务130执行一些步骤而购买者完成其他步骤。
购买者简档260和支付处理270都是很吸引人的，因为鉴权服务130对这些活动来说是自然的集中点。正如采用实际鉴权步骤240-246那样，规模的经济性可通过让鉴权服务130执行这些功能而非要求每个出售者120做这些来实现。
在交易记录阶段206中，鉴权服务130在交易档案170中存储280交易的记录。记录的可信度取决于特定的应用。一个例子中，鉴权服务130可简单地存储交易的明文描述。另一个例子中，数字签署和加盖时间戳的记录可能更适合。继续上面密码的例子，可通过让鉴权服务用其自己的私有密钥对记录进行数字签名来创建数字签名的记录。在私有密钥的例子中，购买者110使用其自己的私有密钥自己创建交易的数字签名记录。在这些例子中，其结果是该交易的不变的、数字签名的记录，它可被购买者110、出售者120或者其他各方用来解决有关交易的争议。
图3-7示意了系统100和方法200的优选实施方案。在因特网实施方案中，在线商务交易发生于基于HTTP的系统上，具体而言就是因特网上。购买者110用传统的万维网浏览器来访问因特网。出售者120是运行因特网上的网站店面的商家，在这种情况下假定是皮特足球商场(Pete’s Soccer Emporium)。该店面运行于传统的万维网服务器上。鉴权服务130也经由万维网服务器与因特网相接口。购买者110想将其信用卡用作支付工具从皮特足球商场购买阿迪达斯Eqt.PredatorAccelerator Cup。用来保证交易安全的保密信息是与支付工具相联系的私有密钥。为方便起见，此实施方案将被称为因特网实施方案，但这并不意味着在暗示此实施方案是因特网可能的唯一方案。
图3是示意因特网实施方案的操作的事件跟踪。正如方法200那样，方法300可粗略分为三大部分购买者注册302、购买者鉴权304和交易记录306。然而，购买者鉴权304和交易记录306的步骤相互交叉。
在购买者注册阶段302中，购买者110建立其与鉴权服务130的“帐户”。在此情况下，这意味着进行了离线调查(如，从信用卡公司接收购买者110被授权使用信用卡的确认)。另外，产生该帐户的私有密钥-公共密钥对并将公共密钥存储312于鉴权服务的数据库150中。在优选实施方案中，公共密钥以表示公共密钥依赖于购买者帐户的数字证书的形式存储。
在此实施方案中，帐户和密钥对依赖于多个支付工具，包括要被使用的特定信用卡。换言之，数字证书和密钥对是用于包含很多支付工具的购买者“钱包”，而非用于一个特定的支付工具。然而，其他实施方案可使用不同的方案，如对每个支付工具使用不同帐户和密钥对。另外，购买者110可具有多个帐户和密钥对。在此实施方案中，购买者的私有密钥和相联系的公共密钥设施(PKI)服务由软件代理为购买者110管理，具体而言就是VeriSign个人信用代理(PTA)。PTA提供一般目的的密钥和证书管理功能并被设计为很容易并入万维网应用当中。
VeriSign PTA管理购买者的PKI凭证。比如，如果购买者110没有数字证书或者密钥对，PTA就将购买者110带到证书登记页面。如果购买者的数字证书很快到期，则在继续前PTA就敦促购买者110更新证书并且可将购买者110带到证书更新页面。类似地，如果购买者的证书已到期，则PTA就提供选项以到达证书更新页面来更新到期的证书。所有这些是通过对于不同浏览器都一致的一组对话来实现的。此外，尽管此特定实施方案使用浏览器，但PTA也可支持其他设备，如无线电话和手持PDA。
PTA和私有密钥可寄宿在多个地点。在此例中，分离的服务器(未示出)上宿有实现PTA的软件并存储相应的私有密钥。该方法的一个优点是，因为PTA和私有密钥实现为零客户、寄宿的服务，所以无需对购买者的浏览器作改变。另一个优点是，因为购买者的浏览器并不要求特别的软件，所以购买者110可能从任何的标准浏览器访问PTA和其私有密钥。有关这如何实现的例子，可参看Warwick Ford于2000年5月17日提交的题为“来自微弱保密的强有力保密的服务器辅助再生”(”Server-Assisted Regeneration of a Strong Secret from a WeakSecret”)的、序列号为No.09/574,687的共同未决美国专利申请，这里引入该主题作为参考。如果宿有该PTA的服务器与宿有该鉴权服务130的相同，则这两个功能可在一定程度上进行集成。在替代的实施方案中，PTA和/或相应的私有密钥实现于购买者的客户机上。比如，PTA可实现为购买者的浏览器的插件(如ActiveX控件)而私有密钥可本地存于购买者的客户机上或在专用硬件(如硬件权标)中。
继续足球的例子，在注册302后，购买者110在皮特商店购物并决定买一些商品。图4是购买者正开始结帐时的购买者浏览器屏幕画面。HTML订购表格400包含订购区域410还有用于快速鉴权的支付的按钮420。订购区域显示这次订购的所有金额加上税共59.95美元。购买者110可用表格的剩余部分，填入信用卡信息、帐单地址等等，以未鉴权方式结帐。然而，购买者110想用鉴权的支付，就点击“AuthPay”(即鉴权的支付)的按钮420。
点击鉴权支付按钮420的结果是，从购买者的浏览器发送330鉴权请求到鉴权服务130。该请求包含支付交易的描述并也识别该出售者120。在步骤340-346中鉴权服务130确定购买者110是否可访问保密信息(在此情况下，是选择的帐户的私有密钥)。鉴权服务130特别发送340询问请求到购买者110。该询问请求要求购买者110用选择的帐户的私有密钥来对一些数据进行数字签名。购买者110发送342其询问响应回鉴权服务130。鉴权服务130取回早先存储的公共密钥并用它确定346购买者110是否可访问该相应的私有密钥。典型地，鉴权过程是在计算机间进行，并没有购买人110的主动参与。
在此实施方案中，为了允许购买者110选择他想使用哪个帐户并且之后从帐户中选择特定支付工具，也要调用PTA。更具体而言，点击按钮420使购买者的万维网浏览器与PTA经由图5A和5B中的对话框进行交互。在图5A中，购买者110通过填入用户姓名域510来指定他想使用哪个帐户并然后通过填入正确密码520来向PTA鉴权他自己。PTA显示图5B的对话框，它包含选择的帐户的视觉表示530。购买者110通过点击登录按钮540来确认他想使用此帐户。该帐户的私有密钥现在就可用于鉴权和数字签名了。
如果购买者110在鉴权步骤失败了，则鉴权服务130进行适当的动作。比如，它可通告出售者120购买者未被鉴权。可替代地，它可拒绝进一步处理该交易并使购买者110返回到早先的屏幕(如结帐屏幕400)。
如果购买者110被鉴权了，则鉴权服务130就将其他购买者简档信息应用到该交易。在此情况下，鉴权服务130取回购买者简档信息并发送此信息到浏览器，如图6示意的表格所示。该信息包含此帐户中不同的支付工具610，也包含不同的运送地址620。此购买者简档信息有很敏感的特性，所以优选地，鉴权服务130在发送此信息给购买者110前先对他进行鉴权。该表格还重申有关该交易的信息630。购买者110选择支付工具610和帐单地址620并通过点击连续按钮来提交该表格。
购买者110和鉴权服务130用图7A和7B示意的表格和对话框来创建380该交易的数字签名记录。为响应表格600的提交，鉴权服务130返回图7A中包含该交易的概要710的表格并要求购买者110授权该交易。购买者110通过点击授权交易按钮来授权。这就调用了图7B的PTA对话框。通过点击签署按钮730，购买者使PTA对概要进行数字签名，因而创建了该交易的数字签名记录。然后鉴权服务130通告350出售者120购买者被授权使用支付工具，并且优选地也通告购买者交易得到批准。
在此实施方案中，鉴权服务130也经由支付网关160为出售者120处理370支付工具，如可由VeriSign得到的Payflow服务。
方法300中在购买者110、出售者120和鉴权服务130间的信息传输是使用传统的万维网技术完成的。比如，注意到表格400由出售者120服务，但点击鉴权支付按钮420就使购买者的浏览器从出售者120切换到鉴权服务130。类似地，一旦完成鉴权过程，购买者的浏览器就从鉴权服务130返回出售者120。
这些传送都是使用传统技术完成的，如GET、POST和/或重定向。比如，传送可通过包含要传递的数据的表格的HTTP POST来完成。这是很具有鲁棒性的，但有时会导致多余的中间网页。然而，可使用自动触发的客户机脚本来消除点击通过中间网页的需要。另一个选项是HTTP重定向到包含要传递的数据的URL。这能消除中间网页，但目前对可传递的数据量有限制(因为只有HTTP GET可重定向)。另一个选项是HTTP重定向到引用要传递的数据的位置的URL，该数据要经由其他一些机制来实际传送。这比其他两种方法更复杂，但可消除中间页面而不限制可传递的数据量。通过其他一些机制发送数据，并在目的地为其分配一个标识符并高速缓存。然后就可用包含该分配的识别符的URL将购买者110重定向。
一个简化的例子中，假设在点击鉴权支付按钮420的时候发送鉴权请求到鉴权服务130。在一个实施方案中，这就通过使用有下列结构的表格400来完成的<form method＝post action＝”http//authpay.verisign.com/authenticate.dll”>
<input type＝”hidden”name＝”return URL”value＝”http//www.seller.com/process”>
<input type＝”hidden”name＝”msg”value＝”PayerAuth Request goes here”>
<input type＝submit value＝”Auth Pay”></form>
http//authpay.verisign.com/authenticate.dll是鉴权服务130的URL.returnURL域规定鉴权完成后购买者110返回的出售者120网站的位置。msg域携带鉴权请求。其他域可用来支持其他功能，如应用简档信息或者支付处理。
一旦完成支付授权过程，购买者110就从鉴权服务130被交回到出售者120，使之经由HTTP POST回到请求中规定的returnURL。传递回出售者120的HTML格式具有下列结构<form method＝post action＝”http//www.seller.com/process”>
<input type＝”hidden”name＝”transID”value＝”123456789”>
<input type＝”hidden”name＝”msg”value＝”PayerAuth Response goes here”>
<input type＝submit value＝”Continue”></form>
transID域包含可被购买者110或出售者120用来指向交易档案170中的交易的交易识别符。msg域携带从鉴权服务130到出售者120的响应。
尽管已经参考其特定优选实施方案相当详细地描述了本发明，但也可能有其他实施方案。比如，在无线(如基于WAP)的实施方案中，购买者110、出售者120和鉴权服务130间的一些或全部通信是经由无线连接或者经由将无线设施与有线设施相连接的网关而发生的。比如，购买者110可从WAP使能的手持设备进行通信。因此，附带的权利要求的范围不应受限于其包含的优选实施方案的描述。
权利要求
1.在包含购买者、出售者和鉴权服务的在线商务交易系统中，一种用于向出售者鉴权购买者被授权把支付工具用作在线商务交易的一部分的处理器实施的方法，该方法包含实时地作为在线商务交易的一部分，该鉴权服务执行下列步骤接收请求以证实该购买者被授权使用该支付工具；确定该购买者是否可访问保密信息而不将该保密信息暴露给该出售者，其中对保密信息的访问证实使用该支付工具的授权；以及根据对购买者是否可访问该保密信息的确定，发送包括购买者是否被授权使用该支付工具的响应到该出售者。
2.权利要求1的方法，其中实时地作为在线商务交易一部分，该鉴权服务还执行步骤将有关购买者的简档信息应用到在线商务交易。
3.权利要求1的方法，还包含根据对购买者可访问该保密信息的确定，鉴权服务至少部分地处理该支付工具。
4.权利要求1的方法，还包含鉴权服务存储该支付工具的使用的记录。
5.权利要求4的方法，其中该记录已由购买者数字地签名。
6.权利要求4的方法，其中该记录已由鉴权服务数字地签名。
7.权利要求1的方法，还包含在在线商务交易之前，该鉴权服务执行下列步骤接收使鉴权服务能确定购买者是否可访问该保密信息的确认信息；以及存储该确认信息；其中确定购买者是否可访问保密信息的步骤包含取回该确认信息；以及使用该确认信息来确定购买者是否可访问该保密信息。
8.权利要求1的方法，其中接收请求以证实购买者被授权使用该支付工具的步骤包括作为来自该购买者的使用该支付工具的提议结果而接收该请求。
9.权利要求1的方法，其中在线商务交易系统是基于HTTP的万维网系统。
10.权利要求9的方法，其中保密信息包含私有密钥，而该私有密钥和对应的公共密钥构成可用于公共密钥密码术中的密钥对。
11.权利要求10的方法，其中实时地作为在线商务交易的一部分，该鉴权服务还执行步骤从购买者接收使用支付工具的提议，其中该提议用私有密钥进行数字签名。
12.权利要求9的方法，其中接收请求以证实购买者被授权使用该支付工具的步骤包含作为购买者使用万维网浏览器提交在线商务交易的表格的结果而接收该请求，该表格包含识别该鉴权服务的动作属性；以及用于作为购买者提交该表格的结果而发送请求到鉴权服务的方法属性。
13.权利要求12的方法，其中该请求还包含该出售者的地址；以及发送响应给出售者的步骤包含发送响应到该请求中包含的地址。
14.权利要求9的方法，其中确定购买者是否可访问保密信息的步骤包含发送询问请求到购买者，请求购买者可访问保密信息的证据；从购买者接收依其申诉证明购买者可访问保密信息的询问响应；以及基于该询问响应而确定购买者是否可访问该保密信息。
15.权利要求14的方法，其中询问请求还包含将使用该支付工具的在线商务交易的描述；以及购买者同意将该支付工具用于该在线商务交易的请求。
16.权利要求9的方法，其中发送包含购买者是否被授权使用该支付工具的响应到出售者的步骤包含将该响应POST到出售者。
17.一种用于向出售者鉴权购买者被授权把支付工具用作在线商务交易的一部分的软件程序产品，该软件程序产品通过由处理器执行该软件来控制处理器的操作，该软件执行下列步骤实时地作为在线商务交易的一部分接收请求以证实购买者被授权使用该支付工具；确定购买者是否可访问保密信息而不暴露该保密信息给出售者，其中对保密信息的访问证实使用该支付工具的授权；以及根据购买者是否可访问保密信息的确定，发送包含购买者是否被授权使用该支付工具的响应到该出售者。
18.权利要求17的软件程序产品，其中，实时地作为在线商务交易的一部分，该软件还执行步骤将有关购买者的简档信息应用到该在线商务交易。
19.权利要求17的软件程序产品，其中该软件还执行步骤根据对购买者可访问保密信息的确定，至少部分地处理该支付工具。
20.权利要求17的软件程序产品，其中该软件还执行步骤存储该支付工具的使用的记录。
21.权利要求20的软件程序产品，其中该软件还执行步骤对该记录进行数字签名。
22.权利要求17的软件程序产品，其中确定购买者是否可访问保密信息的步骤包含取回确认信息；以及使用该确认信息来确定购买者是否可访问该保密信息。
23.权利要求17的软件程序产品，其中该软件程序产品适合于由万维网服务器执行。
24.权利要求23的软件程序产品，其中保密信息包含私有密钥，而该私有密钥和对应的公共密钥构成用于公共密钥密码术中的密钥对。
25.权利要求24的软件程序产品，其中实时地作为在线商务交易的一部分，该软件还执行步骤从购买者接收使用支付工具的提议，其中该提议用私有密钥进行数字签名。
26.权利要求23的软件程序产品，其中接收请求以证实购买者被授权使用该支付工具的步骤包含作为购买者使用万维网浏览器提交在线商务交易的表格的结果而接收该请求，该表格包含识别该鉴权服务的动作属性；以及用于作为购买者提交表格的结果而发送请求到该鉴权服务的方法属性。
27.权利要求26的软件程序产品，其中该请求还包含出售者的地址；以及发送响应给出售者的步骤包含发送响应到该请求中包含的地址。
28.权利要求23的软件程序产品，其中确定购买者是否可访问保密信息的步骤包含发送询问请求到购买者，请求购买者可访问保密信息的证据；从购买者接收依其申诉证明该购买者可访问保密信息的询问响应；以及基于该询问响应而确定购买者是否可访问该保密信息。
29.权利要求28的软件程序产品，其中询问请求还包含将使用该支付工具的在线商务交易的描述；以及购买者同意将该支付工具用于该在线商务交易的请求。
30.权利要求23的软件程序产品，其中发送包含购买者是否被授权使用该支付工具的响应到出售者的步骤包含将该响应POST到出售者。
31.一种带有购买者鉴权的在线商务交易系统包含出售者；想把支付工具用作与出售者的在线商务交易的一部分的购买者；以及通信地耦合到该出售者的鉴权服务，用于实时地作为在线商务交易的一部分执行下列步骤接收请求以证实购买者被授权使用该支付工具；确定购买者是否可访问保密信息而不暴露该保密信息给出售者，其中对保密信息的访问证实使用该支付工具的授权；以及根据购买者是否可访问保密信息的确定，发送包含购买者是否被授权使用该支付工具的响应到出售者。
32.权利要求31的系统，其中鉴权服务还适应用于存储该支付工具的使用的记录。
33.权利要求31的系统，其中鉴权服务使用HTTP协议通信地耦合到该出售者。
34.权利要求31的系统，其中保密信息包含私有密钥，而该私有密钥和对应的公共密钥构成用于公共密钥密码术中的密钥对。
全文摘要
购买者(110)想把支付工具用作与出售者(120)的在线商务交易的一部分并且要求鉴权该购买者(110)具有使用该支付工具的授权。分离的鉴权服务(130)确定购买者(110)是否可访问特定的保密信息而不把该保密信息泄露给出售者(120)。对保密信息的访问可证实购买者(110)有权使用该支付工具。鉴权服务(130)向出售者(120)通告购买者(110)是否被授权使用该支付工具。
文档编号G06Q30/00GK1437741SQ01811338
公开日2003年8月20日 申请日期2001年4月17日 优先权日2000年4月17日
发明者M·E·格拉维斯, P·E·弗兰克, T·普拉姆贝克, G·R·怀特赫德 申请人:弗里塞恩公司