CN105989305A

CN105989305A - 用于通过嵌套式内联框架接收敏感信息的安全服务

Info

Publication number: CN105989305A
Application number: CN201610141164.5A
Authority: CN
Inventors: 玛利亚·尤金伲亚·托纳斯·拉霍兹; 安娜·储-苏米达; 尼昆杰·库拉尔; 彼得·陈; 阿迪提·辛哈·古恩德拉帕里; 苏拉吉特·杜塔; 比努·拉玛克里斯南; 凡卡特什·达玛尔
Original assignee: Excalibur IP LLC
Current assignee: Excalibur IP LLC
Priority date: 2015-03-20
Filing date: 2016-03-11
Publication date: 2016-10-05
Anticipated expiration: 2036-03-11
Also published as: TW201702928A; TWI576719B; EP3070662A1; US20160277421A1; US9942244B2; US20180191735A1; US9251372B1; CN105989305B

Abstract

本公开涉及用于通过嵌套式内联框架接收敏感信息的安全服务。用于接收敏感信息的方法和***包括接收用于输入敏感信息的请求，从用户界面接收到的请求在客户端设备上被渲染。该方法和***取决于嵌套式内联框架，每个内联框架由不同的服务器托管。内部内联框架由安全区内的服务器(例如，数字电子仓库)托管。中级内联框架在安全区内被托管，并被中间服务器调用。外部内联框架由提供用户界面的服务器托管。提供用户界面的服务器可以由例如云服务供应商托管。使用在本公开中描述的嵌套式内联框架和网络拓扑，用户能够通过在安全区外部提供的用户界面与安全区内的服务器交换敏感信息。

Description

用于通过嵌套式内联框架接收敏感信息的安全服务

优先权申请

本申请根据35 USC 119(e)要求于2015年3月20日提交的、序列号为No.62/136,430、题目为“用于通过嵌套式内联框架从数字电子仓库接收支付卡信息的安全服务”的美国临时专利申请的权益和优先权，该申请以其整体通过引用被合并于此。

技术领域

本公开涉及通过分布式网络交换敏感信息。

背景技术

互联网普遍率的提升导致了通过分布式网络交换敏感信息的增加。尽管伴随着安全问题，但是越来越多的商家由于通过呈现可以在任意时间由任意用户通过互联网从任意位置访问的通用数字表示来便捷地进行交易而选择进行线上交易。例如，用户由于方便、可用性、以及便于使用而倾向于网上购物。

当进行线上交易时，用户通常需要提供敏感信息。敏感信息可以包括借记卡或***账号和验证码，例如但还可以包括，病史、测试结果、或用户可能期望保持成隐私的任意其他信息。随着越来越多的交易是通过互联网进行的，敏感信息需要被保护以避免身份盗用变得越来越显而易见，从而吸引用户并保留用户基础。

敏感的财务信息表示在线上交换的所有敏感信息的重要子集。例如，为了协助保护用户的个人数据和财物数据，支付卡行业(PCI)定义了一组数据安全标准(DSS)，任何进行电子商务和收集支付卡信息的交易需要遵守该组数据安全标准，以便保护消费者的身份和保证支付卡信息的安全。在保护支付卡信息时，PCI DSS尤其是对商户是种负担。例如，收集支付卡信息的商户会频繁受到PCI的审计，以确保这些商户所用的支付卡收集服务是服从DSS的，并且不会将用户信息公开给不需要的外部元件。身份盗用成为针对商户和用户的主要问题。

进行线上交易的大多数商家不具有内部的专业技术或资源来满足安全标准(例如，PCI DSS要求)。虽然这些商家承认网络或移动应用的易用性，但是他们不想处理会出现接受和维护安全用户界面和网络的复杂问题。另外，大部分商家想要集中于通过保留他们当前的客户基础来增加客户，并趋向于获得新客户。例如，医疗护理机构(例如，医院或管理式护理机构)可能想要通过网站能够与患者进行通信，而不需要维护其本身必要的专门的人事部门和基础设施来维护患者医疗信息的安全。需要存在改进的方法和***用于通过分布式网络交换敏感信息。

发明内容

本公开描述用于接收敏感信息的方法和***，通过在存储敏感信息的服务器和对最终用户渲染网络页面或移动应用的客户端应用之间引入中间服务器的集合来例如发起对敏感信息(例如，支付卡信息或病史)的请求。各种实施例确保收集敏感信息的商户、医疗护理供应商或其他实体例如能够针对敏感信息提供安全，而不被直接暴露于严格的安全要求，或被设定数据安全标准的行业或委员会所审计和审查，使更少的入侵者盗取敏感信息。

在本公开中，我们将自己首先限定于描述商户如何使用本公开的方法和***来保护客户按照PCI DSS提供的敏感支付信息。然而，需要理解的是，相同的方法和***可以被用来包括任意种类的敏感信息。代替支付信息，该方法和***可以被用来保护例如病史或医疗护理供应商的病患的检查结果。本公开中没有关于方法和***的描述是针对支付信息或需要支付信息的。但是除了另外注明，为了明确和便于解释，我们将自己首先限定于托管用于接收余下公开中的支付信息的商户的示例。

同样地，由商户托管的网络页面中提供的用户界面可以根据本公开以其他方式提供。用户界面可以由本地移动应用提供，其中，使用动态呼叫通过应用编程接口(API)将数据交换到服务器，以接受来自用户界面中的表格的字段的数据，并填充用户界面中的表格。

被用来存储敏感信息的安全服务器通常在安全区(例如，数字“电子仓库(vault)”)内部被保护。相反，用于交换敏感信息的用户界面被安全区外部的服务器(例如，托管网站的服务器)托管。在一个实施例中，中间服务器被提供并且位于安全区外部的服务器和安全区内部的服务器之间的网络。在一些实施例中，中间服务器可以在安全区内部或是在安全区外部。

在很多实施例中，安全服务器、中间服务器、和提供用户界面在安全区外部的服务器可能仅是大量服务器中的一个，作为分布式网络上的***可被一起访问。在一些实施例中，中间服务器可以是***的一部分，该***包括完全位于安全区内的计算机、完全位于安全区外的计算机、或一些在安全区内部和一些在安全区外部的计算机。

中间服务器提供某一级别的间接和分区，从而使商户免于落入任意行业审查或审计的范围内。此外，该级别的间接和分区阻止入侵者访问安全信息(例如，支付信息)，从而使商户免于必须频繁地监控收集安全信息的***以及免于必须执行这种***的复杂的维护。

在一个实施例中，用户界面由应用提供，并且用户界面包括由服务提供的内联框架(iframe)。用户界面被配置为每当敏感信息将被交换时从事服务。服务提供包括复杂内联框架的附加内联框架架构，该复杂内联框架包括被嵌套在第一内联框架内部的至少两个附加内联框架。使用嵌套式的内联框架，用户可以例如输入支付卡详情以完成在线交易。在一些实施例中，嵌套式内联框架可以被用来从现有的支付卡详情中选择已经可用的支付卡详情。例如，选择现有的支付卡详情可以通过API被执行，其中在网络页面上被渲染的用户界面被用来对中间服务器(在本文中还被称为支付用户界面(UI)主机)进行API呼叫，接下来对电子仓库内的安全服务器(在本文中还被称为电子仓库主机)进行API呼叫。在一些实施例中，通过用户界面接收敏感信息的每个字段具有其本身的嵌套式内联框架的集合。嵌套式内联框架在仅遇到最少的服从要求时允许用户界面安全地交换敏感信息，该服从要求可能对接受敏感信息是必要的并且是指定的。

在一个实施例中，通过用户界面接收敏感信息的方法被公开。用户界面可以在网络页面或本地移动应用上被显示。该方法包括提供用于生成表格的至少一个字段的、被用来接收敏感信息的第一内联框架。第一内联框架由安全区内的第一服务器托管。注意的是，已经被分配网络地址的服务器通常被称为“主机”，术语“主机”和“服务器”倾向于交替使用。安全区在本公开中还被称为“数字电子仓库”或仅是“电子仓库”，安全区被定义为从其他网络或公共设备隔离的、一个或多个服务器在其中被托管的区域，使得从其他网络和设备到安全区内托管的服务器的选择性访问或不访问被允许。通常使用一个或多个防火墙来控制访问，但是此外也可以使用其他安全设备。一个或多个防火墙可以根据安全策略被指定，该安全策略对于访问安全区内的服务器指定了非常严格、严密控制的验证和授权过程。

第二内联框架被提供来访问第一内联框架。第二内联框架在安全区内被托管并被第二服务器调用。第二服务器也在安全区内(虽然如上所述，在一些实施例中，第二服务器可以是***的一部分，在该***中一些或全部服务器位于安全区的外部)。调用第二内联框架的第二服务器不同于托管第一内联框架的第一服务器。

第三内联框架被嵌入在用户界面内。第三内联框架被用来使用敏感信息令牌调用第二内联框架。响应于在用户界面处接收到的请求，第三内联框架被安全区外部的第三服务器调用。在一些实施例中，第三服务器托管客户端设备(膝上型计算机、台式计算机、智能电话、或平板计算机)上的网络浏览器的HTML(包括第三内联框架)。在其他实施例中，第三服务器托管由本地移动应用访问的用户界面，接下来在客户端设备(例如，iPhone或安卓设备)上显示内联框架。第二内联框架被嵌套在第三内联框架内部。输入敏感信息的请求从包括至少一个字段的用户界面被接收。响应于接收该请求，第二内联框架通过通过第三内联框架被调用，并且第一内联框架通过通过第二内联框架被调用，用于接收敏感信息。在许多实施例中，第二和第三内联框架从视线中被隐藏，而第一内联框架包括以下可视特性：允许具有至少一个字段的用户界面表格在网络页面上被渲染用于接收敏感信息。

在另一实施例中，方法被公开。该方法包括接收用于交换敏感信息的请求，该请求从在客户端上被渲染的用户界面被接收。请求包括第一访问令牌。作为响应，用户界面主机使用内联框架被调用，并且调用的用户界面主机验证第一访问令牌以及请求中的其他数据。该内联框架被安全区外部的用户界面主机所托管。请求的验证使得用户界面主机撷取用于访问安全区的第二访问令牌。在该实施例中，安全区内的电子仓库主机由用户界面主机通过中级内联框架调用，以验证第二访问令牌。如果已经被调用，则电子仓库主机验证第二访问令牌。在成功验证第二访问令牌时，电子仓库主机提供对安全区内部的内部内联框架的访问。中级内联框架和该内联框架在用户界面中从视线中被隐藏。在成功验证请求时，安全区中的电子仓库主机使用内部内联框架和作为中间级的中级内联框架将响应返回至用户界面。该响应可以包括允许访问用于交换敏感信息的用户界面表格的命令。任何响应通过内联框架被转发至客户端设备，以允许访问用户界面表格中的字段。用户界面表格被用来接收敏感信息。该方法可以针对用户界面表格的每个字段中的数据分别地执行，或者针对用户界面表格的字段中的所有数据一起执行。

在另一实施例中，具有用于执行接收敏感信息的服务的程序指令的非暂态计算机可读介质被公开。用户界面被配置为使用该服务。计算机可读介质包括用于从安全区外部的服务器托管的用户界面中接收请求的程序指令。该请求通过第三、第二、和第一内联框架被接收。第二内联框架在成功验证与请求一起接收的访问令牌时被调用。第一内联框架在成功验证经由第二内联框架接收的安全访问令牌时被调用。计算机可读介质还包括用于在用户界面中从视线中隐藏第二和第三内联框架的程序指令。

在另外的实施例中，方法被公开。该方法包括接收输入敏感信息的请求。该请求从在客户端设备上被渲染的网页中被接收。该请求包括第一访问令牌。用户界面(UI)主机被调用来验证请求中提供的第一访问令牌。UI主机使用内联框架被调用。请求中提供的第一访问令牌使用UI主机被验证。在验证请求时，UI主机撷取用于访问安全区的第二访问令牌。安全区内的电子仓库主机使用第二访问令牌被调用。电子仓库主机被用来验证第二访问令牌。响应从安全区内的电子仓库主机被接收。响应包括允许访问用于输入敏感信息的网页上的UI表格的命令。该响应被转发至客户端设备用于处理，以便允许访问网页上的UI表格。UI表格被用来接收敏感信息。

本发明的实施例因此提供了执行以下操作的简单但又圆滑的方式：保护敏感信息免受入侵者的入侵，同时使商户(或其他服务供应商)免于维护用于接受来自用户的敏感信息的***的复杂性。提供对用来收集敏感信息(例如，支付卡信息)的用户界面上具有字段的表格的访问的重任被集中于指定中间服务器的集合。安全区内部的服务器实施必要的安全和分区控制，使得安全区内的敏感信息不能被经授权的中间服务器以外的任意一个服务器所访问。换言之，访问数字电子仓库内的敏感信息通过实施高标准安全和加密被严格地维护，以保证用户的敏感信息的安全。

本发明的其他方面从以下结合以本发明示例原则的方式示出的附图的详细描述中会变得显而易见。

附图说明

通过参考以下结合附图的描述可以更好的理解本发明。

图1是根据本发明的一些实施例的识别不同类别的服务器的***的简要概述。

图2A示出了根据本发明实施例的线上商户所使用的示例计费页面。

图2B示出了根据实施例的在图2A中用于收集敏感信息的各个字段的计费页面的替代示例。

图3A示出了根据本发明实施例的在嵌套式内联框架内示出表格的示例用户界面。

图3B示出了根据本发明实施例的示出包括嵌套式内联框架的表格的字段的替代示例用户界面。

图4示出了根据本发明实施例的用于提供用户的支付卡信息和其他个人信息的支付平台的示例架构。

图5A示出了根据本发明实施例的响应于用户的支付请求生成的有效访问令牌中所使用的示例安全模型。

图5B示出了根据本发明实施例的有效访问令牌中的每个主机***所起到的作用，以及在请求中所提供的并用于提供对用户的支付请求的响应的其他信息。

图5C示出了其中在数字电子仓库内被验证的支付访问令牌、电子仓库访问令牌、和用户相关可信令牌的本发明的替代实施例。

图6示出了商户的属性计费页面的示例，其中嵌套式内联框架被实现来收集本发明的一个实施例中的支付卡信息。

图7示出了根据本发明实施例的使用嵌套式内联框架来安全地收集支付卡信息的过程流操作的流程图。

图8示出了根据本发明替代实施例的使用嵌套式内联框架来安全地收集支付卡信息的过程操作的流程图。

具体实施方式

本公开描述了用于保护敏感信息(例如，支付卡或其他财务、医疗、或个人的信息)的方法和***。实施例允许托管能够交换敏感信息的网络网页或移动应用用户界面的任意组织通过经由专用的网络架构实现嵌套式内联框架来保护该信息。嵌套式内联框架和网络架构避免向外部元件公开用户界面，从而保护敏感信息。在若干实施例中，嵌套式内联框架会遵守由各个委员会设定的标准(包括PCI DSS)。

用于隔离并保护收集敏感信息的用户界面的要求中的一些要求要求某一安全等级，并且分区控制将在与用户界面相互作用的不同服务器处或在渲染用户界面的不同服务器处被实现。例如，在安全区之外服务用户界面的服务器不应该提供安全功能，例如，对安全区内直接或间接收集敏感信息的其他设备的授权、认证、或访问控制。可以在安全区内被收集并被保护并且需要限制访问的敏感信息的一些示例可能包括社会保障信息、病史数据、密码、安全码、出生日期、其他个人出生记录信息、键控代码、加密代码、通过码、母亲的婚前姓、银行账号、电话号码、就业数据、驾照数据、护照号、和其他护照相关数据、电子邮箱等。当然，前述的列表提供了一些示例，并且可以被收集的敏感信息可能包括在安全区内需要被保护的其他敏感数据。因此，这些外部主机不能发起至安全区内设备的连接，甚至通过中介主机也不能。相反地，来自安全区内的主机不能发起至外部主机的练级。这些外部主机不被允许来处理、存储、或传输敏感数据。服务用户界面的主机和安全区内的主机之间的所有直接连接被主动地阻塞。在一些情况中，这些严格的要求有必要遵守安全标准。本公开描述了用于嵌套内联框架的方法和***，这些方法和***能够遵守严格的安全要求(包括PCIDSS)。

为了清楚以及明确，本公开的剩余部分依据网络页面或本地移动应用用户界面(可通常地被称为“商户属性页面”的“用户界面”)来描述本发明。但是同样的发明可以由用户界面的任意主机使用，不仅是由商户来使用。例如，同样的发明可以由接受敏感医疗信息的医疗护理机构所使用。此外，商户属性页面可以以各种方式被显示。在一些实施例中，属性页面可以被显示在膝上型计算机、台式计算机、或移动设备上的网络浏览器中。在其他实施例中，属性页面可以被显示或被嵌入在属于移动设备的应用中。

在嵌套式内联框架架构中，两个内部内联框架中的每一个由不同的主机所服务和渲染，商户属性页面仍由来自那些服务两个最内部的内联框架的不同主机的另一主机所服务和渲染，允许本领域中未知的间接和分区的级别。该间接和分区的级别允许收集敏感信息而不需要折衷用户的安全和保全。

嵌套式内联框架包括至少三个级别。第一级别(或“内部”)内联框架由安全区(通常，拱形的数据中心或数据中的拱形部分)内的一个或多个服务器所托管。第二级别(“中间”或“中级”)内联框架由在安全区外部的第二服务器或由一些在安全区内而其他在安全区外中的服务器所调用，并针对内部内联框架提供巢。第二内联框架在安全区内被托管。在一些实施例中，第二内联框架由安全区内在与第一级别内联框架所托管的一个或多个服务器不同的一个或多个服务器所托管。注意的是，在实施例中，其中第二级别内联框架可以由安全区内至少一个服务器所托管，该服务器可以不在与托管第一级别内联框架的服务器相同的安全区内。根据该实施例，第二级别内联框架可以由(a)具有与托管第一级别内联框架的(一个或多个)服务器相关联的第一安全级别和(在下文中所描述的)第三安全级别之间的中间级别服务器所托管，(b)在与托管内部内联框架服务器相同的安全区内的服务器所托管，或(c)在与(在下文中所描述的)第三级别相同的逻辑区内的服务器所托管。

第三级别包括托管第三内联框架的(一个或多个)第三服务器，其被第二内联框架所嵌套。第三服务器在安全区的外部。第二和第三内联框架是空内联框架，在用户界面中从视线中被隐藏，并且第一内联框架被包括在提供用于接收敏感信息的字段的用户界面中。注意的是，第一内联框架没有示出，就其没有示出的意义而言就是尽管其仍在由用户界面的主机所服务的HTML中呈现但是不对用户显示。在替代的实施例中，用户界面可以由本地移动应用提供，该本地移动应用使得API通过内联框架进行调用。在这样的实施例中，尽管内联框架仍在与用户界面的主机交换的请求中呈现并可察觉，但是该内联框架还是不对用户显示。

在实施例中，第一内联框架在属性页面被渲染。在该实施例中，第三和第二内联框架包括被配置为保持第三和第二内联框架在属性页面上从视线中被隐藏的渲染特性，而第一内联框架包括被配置为渲染在属性页面的用户界面上形成的用户界面的字段的渲染特性(例如，以用于获得支付卡信息的字段形式)。换言之，基于不同内联框架处的渲染特性的配置，第二和第三内联框架在属性页面上从视线中有效地被隐藏于，而第一内联框架在属性页面可见。嵌套的内联框架可以在属性页面上被行内渲染，或者可以在单独弹出的浏览器窗口中被显示。使用嵌套的内联框架架构，用户可以进入新的支付方法详细说明或从之前定义的方法中选择，这种方法详细说明根据各种代理、委员会、或工业标准设定组织制定的标准和要求所保护。

在本公开中描述的嵌套式内联框架允许来自电子仓库源(即，由安全区内的服务器所托管的内部内联框架)的HTML要素在由中间服务器(即，中级内联框架)托管的HTML内被嵌入，反过来在敏感信息的提交被发起的属性页面的HTML要素内被嵌入。

重要的是，由中级内联框架将内部内联框架从属性页面分离并保护，其允许间接和分区。例如，当持卡人选择使用属性页面上的内联框架来输入支付卡和其他私人信息时，在属性页面上输入的持卡人数据被传送到拱形安全区中的服务器。安全区内的服务器通过用户界面上呈现表格的字段撷取输入的敏感信息、验证相同的敏感信息、加密敏感信息、在安全区内部的存储设备(例如，数据库)内存储加密的敏感信息。因此，即使看起来用户正在属性页面上输入敏感信息，但是嵌套式内联框架确保敏感信息实际被输入在由内部内联框架提供的UI表格的一个或多个字段中，并且敏感信息数据仅用安全区内的服务器来交换。事实上，嵌套式内联框架构成了最终用户和安全区服务区内的服务器之间用于直接通信的通道。

如之前所述，嵌套式内联框架包括外部内联框架、中级内联框架、和内部内联框架。外部内联框架被允许仅调用中级内联框架，中级内联框架被允许调用内部内联框架。因此，属性页面上外部内联框架创建了通过中级内联框架的通道，允许与安全区中的服务器交换敏感信息。在安全区中的服务器处提供了充分的检查，以确保访问安全区仅通过经授权的中间服务器是可用的。通过本发明的简单概述，将参考各个附图来讨论具体实施例。

图1示出了在线上交易过程中用于保护由商户收集的用户的支付卡信息的***的整体分类。在一个实施例中，***的整体分类可以根据PCI或其他委员会设定的标准和要求，该整体分类忽略用户的支付和其他个人或财务信息的保护。根据该分类，用于交易的服务器可以广泛地分类为3个不同的类别：类别1、类别2、和类别3。直接和收集支付卡信息的服务器被分类为类别1服务器。这些类别1服务器具有对数据收集和存储的最高级别的曝光率。为了防止曝光支付卡的相关信息，所有类别1服务器需要遵守严格的安全规范，使得用户的个人和财物数据可以从不需要的外部元件中受到保护。因此，在一些实施例中，类别1服务器在安全区(例如，数字“电子仓库”)内部被维护，从而从网络的其他***中保护和隔离这些服务器。直接连接到安全区内部类别1服务器的服务器或间接连接到安全区内部类别1服务器的服务器被分类为类别2服务器。

类别2服务器在电子仓库的外部并直接或间接地连接到电子仓库内的类别1服务器。在一些实施例中，类别2服务器可以通过其他类别2服务器间接地连接到类别1服务器。这些服务器由于不收集或维护个人和支付卡数据而不具有类别1服务器的严格要求。然而，由于这些服务器与类别1服务器交接，所以在这些服务器内应该实施显著的安全级别。连接到类别2服务器并且在空间中具有足够的分区的服务器被分类为类别3服务器。类别3服务器需要实施某一安全级别，并且分区控制允许这些服务器不会直接或间接影响或折衷由安全区内的分类1服务器收集的支付卡信息。为了避免曝光用户的支付卡或其他敏感信息，安全控制可以被实施来防止类别3服务器直接或间接地连接到类别1服务器，反而是通过中间的类别2服务器。在一些实施例中，针对交易提供属性页面的服务器被分类为类别3服务器。使用这种***的广泛分类，各种实施例将参考剩余的附图被描述。此外，应该理解的是，服务器可以用作主机，其中主机被配置为服务应用。例如，应用可以是由客户端设备访问的客户端应用。在一些实施例中，客户端应用可以定义网站或网站的一部分。

图2A示出了在用户使用客户端设备进行交易需要输入支付卡信息时从客户端设备上渲染的属性页面100被调用的商户账单页面102的示例。属性页面100和商户账单页面102由主机***(例如，服务器)所提供，用于在客户端设备上渲染。客户端设备可以包括能够通过通信网络(例如，经由有线或无线网络)发送或接收信号的计算设备。例如，客户端设备可以是台式计算机或便携式设备(例如，蜂窝电话、智能电话、个人数字助理(PDA)、手持式计算机、平板计算机、膝上型计算机、可穿戴式计算机等)。前述的客户端设备的列表所谓示例被提出，不应该被考虑限定于此。客户端设备可以包括或可以执行各种操作***，包括个人计算机操作***、移动操作***等。客户端设备可以包括或可以执行各种应用，例如，被用来调用账单页面102的应用。

在一个实施例中，账单页面102包括用于收集支付卡信息的用户界面110。用户界面110被提供有内联框架。在图2A示出的实施例中，内联框架是嵌套式内联框架，并且用户界面(UI)被提供为行内UI。在一些实施例中，内联框架可以在客户端的显示器上提供在单独的窗口中被渲染的弹出UI，该客户端设备被用来访问用于进行交易的属性页面100和账单页面102。在其他实施例中，UI可以通过在浏览器上显示的网络页面或通过本地应用在移动设备的移动应用中被提供。在本地应用的情况中，通过UI中表格显示和接收的敏感信息可以通过以HTML格式(包括嵌套式内联框架)做出的API调用被交换。账单页面102是商户的属性页面100的扩充，并因此由安全区外部的主机***(或仅仅是主机)来提供。然而，在账单页面102上提供用户界面110的内联框架提供至安全区的安全访问信道，以允许用户进入支付方法详细说明或是从之前进入的支付方法详细说明中选择。

在一些实施例中，主机***是能够(例如，通过有线或无线网络)发送或接收信号和/或能够处理或存储信号的服务器计算设备。服务器可以在配置和/或功能方面发生变化，但是大多数服务器包括一个或多个处理器(中央处理器)和存储器。服务器还可以包括一个或多个大容量存储设备、一个或多个有线或无线网络接口、一个或多个输入/输出接收、或一个或多个操作***(OS)(例如，服务器、OS X、等)。

敏感信息(例如，支付方法详细说明)的验证由安全区中的服务器提供。在一个实施例中，来自安全区中服务器的成功和失败的响应经由回叫被返回到属性页面102上的用户界面。成功和失败的响应可以在以各个级别的嵌套式内联框架验证访问的过程中被生成，这将会参考图4做出详细的解释。在验证时，在用户界面内以UI表格提供的支付卡信息由安全区内的服务器撷取，在安全区内的数据库中被加密和被存储。应该注意的是，进行交易并收集支付卡信息的商户的每个属性页面包括嵌套式内联框架，以便在收集支付卡信息的过程中提供安全。嵌套式内联框架内的多个内联框架提供了足够的分区，以允许商户属性页面将适用作PCI DSS类别3属性页面并确保商户属性页面曝光最少数量的、在交易中涉及的用户的支付和其他个人、财务和安全相关的数据。

图2B示出了在图2A中示出的商户账单页面的替代的实施例，其中用于交换敏感信息的用户界面(UI)110中渲染的每个字段与相应的嵌套式内联框架相关联。在一个实施例中，针对每个字段的嵌套式内联框架被托管并以与图2A所示的UI的嵌套式内联框架相同的方式使用。

图3A和3B示出了根据本发明的各个实施例的在用户界面上提供的嵌套式内联框架。在图3A和3B二者中，嵌套式内联框架包括至少三个内联框架的组合。首先参考图3A，向用户界面表格提供用于收集敏感信息的一个或多个数据字段的内联框架110-1(还被称为内联框架-1或内部内联框架)由安全区内部的服务器托管。在安全区内托管内联框架-1的服务器接收敏感数据并作出应用编程接口(API)调用，以校验数据并在存储装置中保存数据。托管内联框架-1的服务器在本文中被称为电子仓库主机。在一些实施例中，API呼叫是基于JavaScript对象表示法(JSON)的调用。在一些实施例中，托管内联框架-1的服务器是PCI DSS类别1服务器。在这样的实施例中，类别1服务器不是虚拟服务器。虽然如此，在各个实施例中，这些服务器可以是云网络的一部分、广域网或局域网的一部分。

第二内联框架110-2(还被称为内联框架-2或内部内联框架)被用来调用内联框架-1并且还在安全内被提供。在一些实施例中，内联框架-2被一个或多个类别1服务器所托管。内联框架-2是空内联框架。第三内联框架110-3(还被称为内联框架-3或内部内联框架)被用来调用内联框架-2。内联框架-3位于安全区的外部，并被嵌入在属性页面上以及从属性页面(例如，商户的账单页面)被访问。内联框架-3也是空内联框架，并且仅被用来调用在安全区内被托管的内联框架-2。在一些实施例中，内联框架-3被类别2服务器所托管。在这样的实施例中，类别2服务器可以是虚拟服务器或非虚拟服务器中的一个或多个服务器。托管内联框架-3的服务器被用来验证用户并且信任来自用户请求中提供的cookies，以及用来向安全区内部的内联框架主机传递表格请求信息。内联框架-1在属性页面上是可见的，并且内联框架-2和内联框架-3在属性页面处从视线中被隐藏。即使内联框架-3被隐藏，但是内联框架-3通过隐藏的内联框架-2向内联框架-1提供通道，以允许内联框架-1收集敏感信息。换言之，内联框架-1提供用户界面(UI)表格，用于接收敏感信息。照此，在属性页面处UI表格中输入的敏感信息(例如，支付卡数据)被托管来自安全区内的内联框架-1的主机所收集、验证、加密、和存储。

参考图3B，由服务器托管的用户界面的替代实施例被示出，在图3B的替代实施例中，针对在属性页面提供的用户界面中的表格的每个字段的嵌套式内联框架(例如，110-1a到110-3a、110-1b到110-3b、110-1c到110-3c)被提供。根据该替代的实施例，根据已知的异步JavaScript和XHTML(AJAX)程序模式做出API调用以填充每个字段并且提交每个字段。在实施例中，API调用可以根据诸如iQuery^TM、Angular^TM、Ember^TM、或YUI^TM之类的框架执行。在图3B中示出的嵌套式内联框架以与图3A中所示的嵌套式内联框架相同的方式被托管和使用，区别仅仅在于只有单个字段的数据根据图3B示出的实施例被交换，而整个表格的数据根据图3A示出的实施例被交换。

如上所注意的，针对每个字段的嵌套式内联框架包括在安全区内部托管的内联框架-1(110-1a、110-1b、110-1c)以交换敏感信息数据，内联框架-2(110-2a、110-2b、110-2c)也在安全区内被托管并使用中间服务器被调用，并且内联框架-3(110-3a、110-3b、110-3c)被安全区外部的服务器托管。内联框架-2和内联框架-3是空内联框架，仅用来提供间接的意识而未被配置为收集任何数据。然而，内联框架-1包括由内联框架-1传递的命令所激活的字段。字段被配置为以独立字段的形式交换敏感信息。在一个实施例中，在用户界面(例如，商户的账单页面)和安全区内的服务器之间交换的字段输入数据通过HTML形式的用户界面未完成，而通过超文本传输协议(HTTP)post请求完成。因此，包括敏感信息的字段输入从嵌套式每个字段的内联框架通过内联框架-1(即，内部内联框架)Javascript-^TM使用内联框架到内联框架被收集，并在HTTP post请求中被传输。这种数据交换提供了足够的分区和间接，而提供了具有对外部元件最小限度地曝光用户的敏感信息的敏感数据的传输。

在嵌套式内联框架架构内的内联框架之间流动的数据可以被严格地控制以遵循安全通信协议。例如，必要的头部和充分的安全检查和平衡可以被实现以确保在这些内联框架之间交换的数据对用户不可见，并且不可由外部不需要的元件所辨认。

图4示出了在一个实施例中用来使用具有嵌入的嵌套式内联框架的用户界面安全地交换敏感信息的示例***架构。在图4所示的示例中，用户界面允许用户在商户的账单页面支付。根据该示例，当必须在属性页面(例如，商户的账单页面102-a、102-b、102-c)支付时，调用被嵌入在属性页面中的嵌套式内联框架架构的外部内联框架的请求被发起。托管商户的账单页面的服务器在商户的页面((对PCI DSS而言)是类别3页面)处执行请求中提供的用户数据的初步验证(例如，用户访问数据、用户身份、初步cookie验证)。一经成功验证，在一个实施例中，托管商户的账单页面的服务器调用主机生成第一访问令牌，使用外部内联框架来调用主机(例如，支付UI主机)，并将生成的第一访问令牌与包括用户相关信息的请求一起传递至支付UI主机。在其他实施例中，托管商户的账单页面的服务器撷取与支付UI主机相关联的第一访问令牌，并通过外部的内联框架将撷取的第一访问令牌与请求一起传递至支付UI主机。如果该请求将添加新的支付方法(例如，添加新的***信息、新的借记卡信息等)，则UI模块120被调用来处理支付方法。另一方面，如果现有的支付方法将被选择，则外部的网络服务(EWS)模块130a被调用。第一访问令牌(本文中还被称为敏感信息令牌)和请求将包括必要信息和适当的出发，以识别正确的支付UI主机并调用所识别的支付UI主机内的合适的模块。在该实施例中，支付UI主机充当中间服务器。

在一个实施例中，在请求中提供的信息可以指示用户对添加新的支付方法有兴趣。在该实施例中，支付UI主机通过将请求信息与第一访问令牌一起通过安全区外部的第三内联框架传递来调用UI模块120。安全区(即，数字电子仓库)外部的支付UI主机接收请求信息。支付UI主机可以是一个或多个虚拟或非虚拟的服务器。在一些实施例中，这些虚拟或非虚拟的服务器可以是云网络的一部分或可以是广域网(WAN)或局域网(LAN)的一部分。随后调用的UI模块120执行以第一访问令牌验证开始的一系列验证，以及执行其他验证(例如，用户cookie、安全套接层cookie验证、安全cookie碎屑(Scrumb)验证、碎屑验证等)，以确保请求中提供的信息和第一访问令牌是来自有效的客户端设备的，并且在一些实施例中，调用的UI模块120可以执行额外的验证，以查看已经从事于客户端设备处的商户页面至少预定时间段的请求是否来自用户。前述的验证作为示例示出，包括在请求中提供的其他专有或非专有的数据的更少的或额外的数据被验证。

一经成功验证，由支付UI主机调用的UI模块120识别并撷取第二访问令牌(即，电子仓库访问令牌或安全区访问令牌)，并且将第二访问令牌与来自请求的其他数据一起通过第二内联框架传递至安全区内的UI-电子仓库模块125。根据PCI DSS标准，支付UI主机可以是类别2主机，并且安全区内的第二内联框架(即，数字电子仓库)被支付UI主机所调用。

在一个实施例中，在安全区中执行的电子仓库主机的UI-电子仓库模块125通过第二内联框架接收第二访问令牌(也被称为电子仓库访问令牌)和请求中提供的其他数据(例如，cookie的第二集合)，验证第二访问令牌并执行其他数据(例如，cookie的第二集合)的额外验证。在一些实施例中，cookie的第二集合与通过外部内联框架传递的cookie和令牌信息的集合相同。在一些实施例中，UI-电子仓库模块125可以是由不只一个UI-电子仓库模块组成的合成UI-电子仓库模块，其中每个UI-电子仓库模块由安全区内的单独的电子仓库主机托管。在一些实施例中，在合成UI-电子仓库模块内的每一个UI-电子仓库模块可用来执行请求内提供的数据中一些具体数据的验证。在一些其他的实施例中，合成UI-电子仓库模块内的第一UI-电子仓库模块可被用来提供安全区内某一级别的间接或分区，而合成UI-电子仓库模块内的第二UI-电子仓库模块可被用来执行请求中提供的数据的验证。

在一些实施例中，UI-电子仓库模块125除了接收第二访问令牌和请求中提供的其他数据之外还接收第一访问令牌。在这些实施例中，UI-电子仓库模块125可以在验证第二访问令牌和其他数据之前首先验证第一访问令牌。在一些实施例中，UI-电子仓库模块125可以包括两个子模块：UI-电子仓库1子模块125-a和UI-电子仓库2子模块125-b，其中每个子模块使用第二内联框架执行所提供的数据中一些具体数据的验证。例如，UI-电子仓库1子模块125-a可以执行第二访问令牌和请求中提供的其他数据的验证，而UI-电子仓库2子模块125-b可以执行请求中提供的第一访问令牌的验证。在替代的实施例中，UI-电子仓库1子模块125-a可以执行第一访问令牌和其他数据的验证，而UI-电子仓库2子模块125-b可以用来验证第二访问令牌。在这些实施例中，第一访问令牌被验证了两次-第一次由安全区外部的支付UI主机(第二类别主机)验证，第二次由安全区内部的电子仓库主机(类别1主机)验证。

根据其中UI-电子仓库模块125在电子仓库主机内被提供的实施例，UI-电子仓库模块125可以首先验证第二访问令牌，以确保令牌来自经授权的支付UI主机，该经授权的支付UI主机被允许与电子仓库主机进行通信。由于UI-电子仓库模块125在安全区200(即，数字电子仓库或仅仅是“电子仓库”)内，访问UI-电子仓库模块125被严格控制。因此，电子仓库主机接收的任意通信需要被验证，以确保其接受的令牌和请求仅来自可信的来源。在一些实施例中，UI-电子仓库模块125可以相对于主机数据库验证第二访问令牌，以确保发送第二访问令牌的支付UI主机是有效的并且可信的来源。在验证支付UI主机时，UI-电子仓库模块125可以以类似于支付UI主机内的UI模块120执行验证的方式来执行请求内提供的其他数据的验证。前述验证请求中提供的数据的步骤可以被扩展为合成UI-电子仓库模块或两个UI-电子仓库子模块(UI-电子仓库1子模块125-a和UI-电子仓库2子模块125-b)在UI-电子仓库模块125内被提供，其中每个子模块执行请求中提供的数据中一些具体数据的验证的实施例。

为了验证来源和用户或请求中提供的主机相关的信息，执行UI-电子仓库模块125的电子仓库主机可以占用应用编程接口/内部网络服务(API/IWS)模块130-b以确保第一访问令牌是来自可信的来源的。在实施例中，其中用户界面由本地移动应用所提供，所有从用户接收到的数据可以通过API/IWS模块130-b被接收。API/IWS模块130-b可以依次从外部网络服务(EWS)模块130-a接收必要的cookie和其他用户相关的和主机相关的信息，并执行第二访问令牌和安全区内其他数据(在一些情况中包括支付访问数据(如果被提供的话))的验证。

在一个实施例中，EWS模块130-a访问云资源服务300，以从云资源302、304、306等的集合中撷取验证信息。这些云资源中的每一个可以提供用于验证的某一类型的数据。例如，云资源1可以提供用户-访问和可信cookie数据以核查请求中提供的用户-访问和可信cookie，云资源2可以提供数据以验证超文本传输协议(HTTP)请求，从而确保第一访问令牌内提供的HTTP请求不是随机HTTP请求等等。在一些实施例中，EWS模块130-a仅被配置为执行从云资源撷取相关的数据，并将撷取的数据发送至API/IWS模块130-b，用于验证请求中提供的其他数据。在这样的实施例中，云资源服务300可以是代替类别1***的类别2***的一部分，如图4所描述的。在其他实施例中，EWS模块130-a可以帮助验证一些请求中提供的其他数据。

在一些实施例中，UI-电子仓库125可以提供哪一个支付UI主机可以访问安全区的限制，这种限制可以使用X-框架选项来指定。例如，X-框架选项可以被用来定义HTTP响应头部，以指示哪一个支付UI主机可以被允许访问UI-电子仓库。X-框架选项提供额外的检查以确保来自未授权的支付UI主机的内联框架没有在尝试访问安全区中的数据。

在一些实施例中，验证操作是双向操作，其中支付UI主机内的UI模块核查以确保第二内联框架在安全区内正尝试调用的第一内联框架是来自正确的电子仓库主机，而电子仓库主机的UI-电子仓库模块125正在托管安全区内的第一内联框架(即，内部内联框架)，核查以确保通过第二内联框架提供的第二访问令牌数据是来自可信的并且经授权的支付UI主机。该双向核查提供齐整的检查和平衡以确保通过第二内联框架提供第二访问令牌的支付UI主机不被折衷。

在一个实施例中，请求中提供的信息可以指示用户对选择现有的支付方法感兴趣。在该实施例中，支付UI主机调用EWS模块130-a。EWS模块130-a与API/IWS 130-b相互作用来提供从一个或多个云资源服务300获得的必要数据，使得API/IWS 130-b可以验证令牌和请求中提供的其他数据信息。如之前所述，EWS模块130-a没有做出任何验证，仅向API/IWS模块130-b提供用于验证的必要数据，API/IWS模块130-b执行请求中提供的所有数据的验证。API/IWS模块130-b在安全区内执行验证。

在一些实施例中，请求可以被导向访问现有支付方法，该方法识别用来为电子商务交易缴费的支付卡，基于重新签发的卡来改变地址、更新支付卡信息，或者改变、添加、或删除与现有支付卡相关的其他数据。在这样的实施例中，EWS模块130-a与一个或多个云资源相互作用以获得卡数据信息，并且与API/IWS模块130-b相互作用以提供卡数据信息，从而在成功验证请求中提供的数据时，用来从中选择的卡数据的列表可以被呈现。在一个实施例中，该列表可以以加密控键的形式提供卡相关的数据。在该实施例中，实际卡数据被保持隐藏，以保护用户支付信息的隐私。在一些实施例中，EWS模块130-a被配置为处理每个交易请求，而不是添加新的支付卡数据，每个交易请求通过安全区内的UI-电子仓库模块被处理。在一个实施例中，EWS模块可以通过API被访问，以维护用户的支付数据。不考虑访问特定支付方法本质，执行UI-电子仓库125的电子仓库主机通过本文所指示的验证过程来确保请求来自有效的属性页面(类别3服务器)、来自从事属性页面至少预定时间段的用户、并通过经授权的支付UI主机(类别2服务器)被接收。

在成功验证第一访问令牌时，第二访问令牌和请求中提供的其他数据、支付卡信息可以被加密并被保存在安全区中维护的数据存储装置140(例如，卡数据库)中。另外，通知可以被发送回商户属性页面以指示在电子商务交易中指示的适当的支付金额已经被计入客户的账户，并且被存入商户的账户。在一个实施例中，通知DQ模块127可以从事生成用来指示收费明细的通知消息。由安全区内电子仓库主机提供的任意消息、通知、或数据不能被直接发送到适当的商户的属性页面(102-a、102-b、102-c等)，由于直接的消息、通知、或数据利用的通知路径可能曝光安全电子仓库主机的一个或多个服务器，从而受到不需要的外部元件的攻击。为了防止这种曝光，对属性页面的通知可以通过通知中继模块129来传递。通知中继模块129在安全区的外部，但是在适当位置包括足够的检查和平衡以确保访问电子仓库主机不被折衷或暴露。

在一些实施例中，除了向各自的属性页面提供通知，还可以向财务核算服务(例如，核算模块或服务(OFA)150)提供通知消息中所提供的信息，以允许记录由商户的属性页面处的各个电子商务交易生成的收入。财务核算模块或服务可以是商户的基础设施的一部分，或可以是主机的基础设施的一部分。对于被用来验证敏感数据(例如，敏感的医疗信息、敏感的个人信息等等)的实施例，类似的记录服务可被从事于生成在请求中交换的敏感信息的日志。在一些实施例中，在通知消息中提供的信息还可以被用来更新在一个或多个云资源服务300中维护的一些用户相关的、会话相关的、和/或主机相关的特性，从而在后续请求从网络页面被接收到时，当前数据由一个或多个云资源服务(302-306)提供，以验证或核查请求中的数据。例如，当用户使用新的客户端设备访问属性页面时，提供到新的客户端设备和/或由新的客户端设备提供的cookie可以被存储在云资源302-306中，使得cookie和其他数据的验证可以是快速和精确的。

云资源服务(302-306)可以被用来配置管理、验证从不同的来源和不同的平台等接收到的各种cookie。EWS模块130-a用作中心访问点，用于提供用来验证请求中提供的访问令牌的必要数据。因此，EWS模块与各个云资源服务器相互作用，以在支付卡信息可以被加密并被保存在存储装置之前撷取必要数据并向安全区内的API/IWS模块提供相同的必要数据用于验证请求。

在一个实施例中，在电子仓库主机的API/IWS模块130-b执行第一访问令牌和第二访问令牌(即，电子仓库访问令牌)的验证之后，收费明细被转发到适当的卡或金融机构，使得用户的账户可以为交易缴费。API/IWS可以使用一个或多个支付处理器160将这种信息传递到金融机构。支付处理器160是安全网络的一部分的服务器的集合，并且API/IWS和支付处理器160之间以及支付处理器和金融机构之间的任何通信遵循由相关行业建立的通信协议的严格的指导说明。

图5A示出了在一个实施例中由支付UI主机和电子仓库主机执行的安全检查的示例列表，以验证从客户端设备的用户接收到的请求。在该示例中，客户设备被配置为访问客户端应用(例如，客户端应用1-n)。客户端应用由网站(例如，可以使用一个或多个服务器)托管。网站被认为是类别3服务器。如上所注意的，类别3服务器可以托管应用(例如，客户端应用)。在图5A中，客户端应用3被例如网站所托管。客户端应用3可以运行以接收敏感信息。敏感信息通常是数据。任何类型数据在被传送时需要安全，这可从本文描述的实施例中获益。为了当前示例，敏感信息可以是支付信息(例如，***信息)。

仍参考图5A，支付UI主机被示为类别2服务器。支付UI主机使用内联框架-3处理提供的数据。在一些实施例中，支付UI主机被称为中间服务器。支付UI主机被配置为在成功验证数据时，使用内联框架-3核查提供的数据，并将第二访问令牌传递到电子仓库主机，该电子仓库主机是(一个或多个)类别1的服务器。电子仓库主机执行由支付UI主机的内联框架-3调用的内联框架-2，并且内联框架-2被配置为提供对内联框架-1的访问，内联框架-1还由电子仓库主机执行或安全区内的另一主机执行。如本文中所使用的，嵌套式内联框架因此参考内联框架-1被嵌套在内联框架-2中以及内联框架-2被嵌套在内联框架-3中的这一事实。

继续参考图5A，当用户选择商户的属性页面上的支付选项时生成请求。由客户端设备访问的客户端应用(例如，客户端应用1-n中的任意一个)从事提供嵌套式内联框架的服务。例如，客户端应用可以在包括任意类型内容的任意网站上。一个示例网站可以是属性页面。如本文所使用的，属性页面参考包括某些类型的内容(例如，新闻、娱乐、股票等)的网页。在一个实施例中，客户端应用使用由用户提供的用户相关的cookie和可信cookie来验证其本身。如果客户端应用不能验证其本省，则客户端应用将撷取用户相关的和/或可信的cookie的新的集合。利用有效的用户cookie，客户端应用从事嵌套式内联框架服务。该服务被用来撷取访问令牌(在一个实施例中是支付访问令牌)，以调用与支付访问令牌相关联的支付UI主机，并使用内联框架将请求中提供的数据与支付访问令牌一起传递用于验证。

被用来调用支付UI主机的内联框架是在安全区外部的外部内联框架(即，内联框架-3)，并在商户的属性页面(例如，网络页面)上被提供。被传递到支付UI主机用于验证的一些数据包括支付访问令牌，与用户、会话、应用和主机相关的各种cookie。例如，cookie可以包括用户访问cookie(例如，令牌)和可信cookie(例如，令牌)、安全cookie碎屑(Scrum)、碎屑、安全套接层(SSL)cookie等。应该注意的是，前述的数据作为示例被提供，并且更少的或额外的数据可以与支付访问令牌一起被传递至支付UI主机，或仅仅将支付访问令牌传递至支付UI主机。

支付UI主机接收由外部内联框架传递的令牌和数据，并且验证客户端应用的请求。在一些实施例中，支付UI主机以特定顺序验证请求。在一些其他的实施例中，由支付UI主机执行验证的顺序可以变化。验证的示例顺序在图5A中被示出。当然，在图5A中示出的验证次序和类型是说明性的。如所示，支付UI主机是在安全区外部的类别2主机。支付UI主机验证通过首先验证支付访问令牌来验证由客户端应用从事的服务提供的数据。在验证过程中，如果支付访问令牌被发现是无效的，则支付UI主机通过作为响应的访问错误将请求返回到由客户端应用从事的服务。在成功验证支付访问令牌之后，支付UI主机通过外部内联框架以图5A中描述的顺序或以任意其他顺序验证具有支付访问令牌的数据的剩余部分。如果该数据中的任意一个是无效的，则通过作为响应的相应的错误将请求返回。

一旦客户端应用请求被成功验证，则支付UI主机撷取安全区的访问令牌(还被称为“第二访问令牌”或“电子仓库访问令牌”)。支付UI主机通过调用中级内联框架(内联框架-2)与电子仓库主机相互作用。支付UI主机可以传递电子仓库访问令牌和由外部内联框架传递的信息中的一些或全部。由支付UI主机通过中级内联框架传递的信息可以包括对验证请求是有用的一个或多个用户相关的、会话相关的、应用相关的、主机相关的和/或任意其他专有或非专有的信息。例如，可以被用来调用电子仓库主机的一些信息可以包括由外部内联框架传递的相同用户cookie、Scrumb、crumb、SSL cookies，或可以包括由支付UI主机传递的信息的不同集合。在一个示例中，除了电子仓库访问令牌、用户cookie、Scrumb、crumb、SSL cookies等，支付访问令牌还可以被传递至电子仓库主机用于验证。用来调用电子仓库主机的信息的上述列表作为示例被提供，并且不应该被认为是限定性的。更少或额外的用户相关的、会话相关的、应用相关的、主机相关的数据可以被用来调用电子仓库主机，只要这种信息已经被外部内联框架所提供或被支付UI主机所提供。

在一些实施例中，一些级别的分区可以通过引入支付UI主机和电子仓库主机之间的一个或多个附加的中间服务器(例如，(一个或多个)类别2服务器)被提供。应该注意的是，支付UI主机是被调用来执行支付访问令牌的验证和撷取电子仓库访问令牌的中间服务器(类别2服务器)。在这些实施例中，附加的中间服务器可以从支付UI主机接收信息，在将信息通过中级内联框架转发至电子仓库主机之前执行附加级别的验证，用于更彻底地验证或附加验证。根据这些实施例，附加的中间服务器中的一个或多个服务器可以被配置为通过经由中级内联框架或由附加的中间服务器生成的单个信号传递电子仓库访问令牌和其他数据来调用电子仓库主机，在成功验证时，请求支付UI主机通过中级内联框架调用电子仓库主机。该分区向电子仓库主机提供附加级别的安全，从而防止安全区外部的任何服务器任意直接访问电子仓库主机。

在调用电子仓库主机时，电子仓库主机执行通过中级内联框架传递的数据的验证。例如，响应于调用中级内联框架，电子仓库主机可以首先验证支付访问令牌，以确保经授权的支付UI主机访问电子仓库主机。在验证过程中，如果确定未授权的支付UI主机正在尝试访问电子仓库主机，则电子仓库访问错误作为响应被返回到请求。在验证支付访问令牌之后，电子仓库主机继续验证电子仓库访问令牌。如果电子仓库访问令牌被发现为无效，则电子仓库主机通过作为响应的电子仓库访问错误将请求返回。一旦电子仓库访问令牌已经被验证，则由支付UI主机提供的其他数据可以被验证。当其他数据中的任意一个被发现为是无效的，则通过作为响应的相应的错误将请求返回到支付UI主机。

一旦所有的其他数据已经被验证并且支付UI请求已经被视为真实的和有效的，则电子仓库主机提供内部对内联框架的访问，该内部内联框架返回包括在内部内联框架(例如，内联框架-1)内的支付用户界面(UI)表格的页面响应。支付UI表格可以包括用于收集敏感信息的一个或多个字段。在一些实施例中，响应还可以具有被限定于支付UI域的X框架头部。在X框架中提供的信息允许电子仓库主机执行其自身对支付UI主机的验证，以及允许支付UI主机执行其自身对电子仓库主机的验证。该双向验证确保除了经授权的支付UI主机不能被任意其他主机“内联框架d”(即，通过内联框架访问)，并且通信是在电子仓库主机和经授权的支付UI主机之间。

在响应中提供支付UI表格被返回到客户端用于在客户端的属性页面上渲染，以供收集支付卡信息。在一些实施例中，渲染支付UI表格可以包括在属性页面处不隐藏支付UI表格，并且由电子仓库主机提供的响应可以包括激活不隐藏支付UI表格的渲染特性的命令。如图5A所示，应该注意的是，内联框架-2和内联框架-1在数字电子仓库(即，安全区)内，并且数据的验证在安全区内被执行。另外，内联框架-2和内联框架-3在属性页面(例如，请求被发起的商户的网络页面)处从视线中被隐藏。

图5B示出了在验证请求中提供的数据中每个类别主机起到的作用。首先，提供被用来接收支付卡信息的网络页面(即，商户账单页面)的主机验证其本身，以及验证被发起的用于输入支付卡信息的请求。提供网络页面的主机是类别3主机。在成功验证请求时，主机使用内联框架-3调用支付UI主机并传递请求和识别支付UI主机的支付访问令牌，用于由支付UI主机的验证。支付UI主机是类别2主机。支付UI主机执行支付访问令牌和请求中提供的其他数据的验证，并且撷取电子仓库访问令牌。支付UI主机随后调用电子仓库主机，并将电子仓库访问令牌与请求一起通过内联框架-2传递至电子仓库主机。

通过内联框架-2提供的数据被电子仓库主机(为类别1主机)验证，在成功验证时，访问被提供有请求的内联框架-1，以提供用于接收支付卡信息的UI表格。电子仓库主机可以传递必要信息，用于通过内联框架-1渲染UI表格。在一个实施例中，通过内联框架-1传递的信息包括在网络页面处不隐藏UI表格的命令。基于该命令，支付UI主机将UI表格返回至网络页面(即，商户的账单页面)，用于渲染以及用于接收支付卡信息。

图5C示出了实施例，其中支付UI主机在验证支付访问令牌和请求提供的其他数据时撷取电子仓库访问令牌，并将撷取的电子仓库访问令牌、支付访问令牌、和请求中提供的其他数据传递至电子仓库主机。电子仓库主机执行由支付UI主机发送的数据的验证。核查的次序可以包括首先核查支付访问令牌，如图5C中所示(以确保经授权支付UI主机与电子仓库主机相互作用)，接下来核查电子仓库访问令牌，并随后核查请求中的其他数据。在替代的次序中，首先可以核查电子仓库访问令牌，接下来核查支付访问令牌，并随后核查请求中的其他数据。不考虑以下的验证次序，在成功验证所有的数据时，电子仓库主机可以提供对内联框架-1的访问，并发出在商户的网络页面处不隐藏UI表格(例如，支付UI表格)的命令。电子仓库主机和支付UI主机可以在使支付UI表格在商户的网络页面可用之前以许多方式和/或次序独立地执行各自请求中提供的数据的验证，用于收集支付卡信息。如上所述，在用于渲染商户的网络页面上的支付UI表格的信息被提供之前，不只一个支付UI主机可以被用来执行源于网络页面的请求中提供的数据的必要验证。

图6示出了根据本发明的实施例的被用来调用嵌套式内联框架用于进入支付方法的示例商户账单页面，该实施例中敏感信息是支付卡信息。图6的嵌套式内联框架允许与表格中各个字段有关的数据用电子仓库主机通过商户的网络页面中提供的用户界面被交换。示例商户账单页面与添加广告活动有关。如所示，广告管理页面(即，商户的账单页面)被类别3主机渲染，类别3主机包括用于收集支付卡信息细节的嵌套式内联框架。被渲染的内联框架包括可以从账单页面(类别3页面)调用的并且是空壳的外部内联框架(内联框架-3)、可以从外部内联框架调用的并且也是空壳的在安全区内部的中级内联框架(内联框架-2)(中级内联框架被安全区外部的UI主机所调用)、和可以只被内联框架-2调用并被安全区内部的主机托管的内部内联框架(内联框架-1)。不同于是空壳的内联框架-2，内联框架-1提供包括多个字段的用户界面表格，以从持卡人收集支付卡和其他安全相关的信息。在一个实施例中，空壳提供了某种程度上的抽象以便引入间接，使得从外部内联框架到内部内联框架的访问不是直接的，而是被迫通过调用中级内联框架的中间服务器。在另一实施例中，空壳引入了某种程度上的分区，使得从外部内联框架到内部内联框架的访问被迫通过中级内联框架。该间接或分区的意识在允许用户和商户从事电子商务交易时允许***保护支付卡信息，而不需要解决维护或遵守任意严格的行业或机构的要求的复杂性。

通过以上详细描述的各种实施例，参考图7来描述方法。该方法从操作710开始，其中用于交换敏感信息的请求从在客户端设备上被渲染的用户界面被接收。用户界面可以是用于执行交易的商户的网络页面。该请求在用户界面处被验证，并且与用户界面(UI)相关联的第一访问令牌被撷取。如操作720中所示，使用内联框架来调用UI主机。如操作730中所示，第一访问令牌和请求中提供的其他数据由UI主机验证。验证可以通过定义的次序，即通过首先验证识别UI主机的第一访问令牌。一旦第一访问令牌的验证成功，则请求中提供的其他用户相关的、会话相关的、主机相关的数据(例如，cookies)等由UI主机验证。请求的验证使UI主机撷取用于访问安全区的第二访问令牌。

如操作740中所示，通过传递第二访问令牌由UI主机使用中级内联框架(即，内联框架-2)来调用安全区内的电子仓库主机。响应于调用，电子仓库主机首先验证第二访问令牌，以确保该令牌来自有效的UI主机，该UI主机被授权与电子仓库主机进行通信，并且其请求是有效的请求。在成功地验证被UI主机转发的请求时，电子仓库主机将提供对内部内联框架(即，内联框架-1)的访问。内联框架和中级内联框架在用户界面中从视线中被隐藏。内部内联框架会将响应经由中级内联框架(即，内联框架-2)返回至UI主机，该响应包括用于渲染内部内联框架(即，内联框架-1)内的UI表格的信息。在内部内联框架中提供的信息可以包括不隐藏内联框架-1中提供的UI表格的命令。如操作750中所示，UI主机接收包括不隐藏命令的响应，以允许访问用户界面上用于交换敏感信息的UI表格。响应被返回到客户端设备，在客户端设备处命令被处理，UI表格在UI界面上被渲染并使得能够访问UI表格。UI表格被用来接收敏感信息。

在另一实施例中，用于接收敏感信息的方法现在将参考图8被讨论。用户界面(例如，网络页面)被配置用来使用服务。在一些实施例中，可以通过托管网络页面上的嵌套式内联框架(内联框架)架构来访问服务。该方法从操作810开始，其中第一被提供用于生成至少一个字段的表格并用于从至少一个字段的表格接收敏感信息。第一内联框架由安全区内的第一服务器托管。如操作820中所示，第二内联框架被提供来调用第一内联框架。第二内联框架被托管在安全区内，并由第二服务器调用。如之前所述，根据实施例，第二内联框架可以由安全区内的服务器以针对第一服务器定义的第一安全级别和与第一安全级别不同的第二安全级别之间的安全级别托管、由与托管第一内联框架的第一服务器相同的安全区内的服务器托管、或由与第二安全级别相同的逻辑区内的服务器托管。

第二内联框架被配置为使用由第二服务器撷取的访问令牌(例如，安全区访问令牌)来调用第一内联框架。第一内联框架被嵌套在第二内联框架内。如操作830中所示，第三内联框架被提供用于嵌入在客户端设备上被渲染的用户界面(例如，网络页面)。响应于在用户界面处接收到的请求，第三内联框架由安全区外的第三服务器调用。第三内联框架被用来使用敏感信息令牌调用第二服务器。第二内联框架被嵌套在第三内联框架内部。如操作840中所示，交换敏感信息的请求通过用户界面被接收。请求包括敏感信息令牌。响应于接收用于提供敏感信息的请求，第二内联框架通过第三内联框架被调用，第一内联框架通过第二内联框架被调用。

请求的处理允许UI表格被返回用于通过第一内联框架在用户界面上渲染。在一些实施例中，请求的处理是命令经由第一内联框架被返回，以调整被包括在第一内联框架中的UI表格内至少一个字段的渲染特性，以便不隐藏UI表格中的至少一个字段，并将UI表格渲染在客户端设备上提供的网络页面处的用户界面上。UI表格中不隐藏的(一个或多个)字段被用来输入敏感信息。嵌套式内联框架架构的第二和第三内联框架在用户界面处从视线中被隐藏，第一内联框架渲染UI表格。UI表格上提供的敏感信息被第一处理器所处理，并被存储在安全区中维护的数据库内。

嵌套式内联框架架构在安全区外部的第三服务器提供用于渲染UI表格的窗口时允许以安全的方式收集与用户相关的敏感信息(例如，支付卡和其他财物、私人信息)。使用嵌套式内联框架收集和保护私人的以及财物信息的这种方式需要在商户的属性页面(即，在属性页面嵌入嵌套式内联框架)处的极小的改变以允许调用适当的内联框架主机，允许商户继续关注他们在他们的属性页面处吸引和留住客户的生意。

通过上述考虑到的实施例，应该理解的是本发明可以利用包括被存储在计算机***的数据的各种计算机实现的操作。这些操作可以包括物理转变数据、保存数据、和显示数据。这些操作是那些需要物理操纵物理量的操作。通常，虽然不是必要的，但是这些物理量采取能够被存储、传输、合并、比较、和以其他方式***纵的电气或磁信号的形式。在通过网络捕获和传输的过程中，数据还可以被存储在网络中。例如，存储装置可以在网络节点处，并且可以是与服务器和其他计算设备(包括便携式设备)相关联的存储器。

在本文中描述的、形成本发明的一部分的任意操作是有用的机器操作。本发明还与用于执行这些操作的设备或装置有关。可以针对所需的目的专门地构建装置，或者该装置可以是通过计算机中存储的计算机程序选择性激活或配置的通用计算机。具体地，各种通用的机器可以根据本文的教导与写入的计算机程序一起使用，或构建执行所需操作的更为专业的装置可能会更方便。

本发明还可以被体现为计算机可读介质上的计算机可读代码。计算机可读介质是可以存储数据的任意数据存储设备，该数据在其后可以由计算机***读取。计算机可读介质还可以通过网络耦合的计算机***被分布，使得计算机可读代码以分布的方式被存储和被执行。

虽然为了清楚和理解的目的相当详细地描述了前面的发明，但是在所附权利要求的范围内可以实践某些改变和修改是显而易见的。因此，当前的实施例将被认为是示意性的而不是限定性的，并且本发明不限于本文给出的细节，而是可以在所附权利要求的范围和等同中被修改。

Claims

1.一种用于接收敏感信息的方法，所述方法包括：

提供用于生成表格的至少一个字段并且用于从所述表格的至少一个字段接收所述敏感信息的第一内联框架，所述第一内联框架由安全区内的第一服务器托管；

提供第二内联框架来访问所述第一内联框架，所述第二内联框架在所述安全区内被托管并被第二服务器调用，所述第二服务器已经由所述安全区外部的第三服务器调用；

提供第三内联框架，所述第三内联框架由所述安全区外部的所述第三服务器调用，响应于用户界面处接收的请求，所述第三内联框架已经被调用；

在所述用户界面中从视线中隐藏所述第二内联框架和所述第三内联框架；以及

在通过针对所述表格的至少一个字段的所述用户界面接收到用于提供敏感信息的所述请求时，通过所述第三内联框架调用所述第二内联框架并通过所述第二内联框架提供对所述第一内联框架的访问，

其中方法操作由一个或多个处理器执行。

2.如权利要求1所述的方法，其中，所述第二服务器包括由云服务供应商托管的虚拟服务器。

3.如权利要求1所述的方法，还包括：

使用由所述第三服务器托管的程序逻辑验证所述请求；以及

在成功验证所述请求时，使用所述第三内联框架调用所述第二服务器并传递敏感信息令牌和所述请求中提供的其他数据。

4.如权利要求1所述的方法，还包括：

由所述第二服务器通过所述第三内联框架验证敏感信息令牌和所述请求中提供的其他数据；

在成功验证所述敏感信息令牌和所述请求中提供的其他数据时，识别并撷取安全区访问令牌；

使用所述第二内联框架调用所述第一服务器；以及

使用所述第二内联框架将所述安全区访问令牌和所述请求传递至所述第一服务器。

5.如权利要求1所述的方法，还包括：

使用所述第一服务器通过所述第二内联框架验证安全区访问令牌和所述请求中提供的其他数据，其中验证引起提供对所述第一内联框架的访问。

6.如权利要求1所述的方法，还包括：

使用所述第一内联框架将命令通过所述第二内联框架转发至所述第三内联框架，以显示所述用户界面上的所述表格的至少一个字段，用于接收所述用户界面上的所述敏感信息。

7.如权利要求1所述的方法，其中，所述请求包括用户相关的数据、会话相关的数据、***相关的数据、或应用相关的数据。

8.如权利要求1所述的方法，其中，所述敏感信息包括支付卡信息。

9.如权利要求1所述的方法，还包括：

向所述用户界面提供通知，所述通知识别与对由所述敏感信息识别的账户发起的收费相关的数据，所述通知从所述第一服务器通过安全通知中继服务被提供。

10.一种方法，包括：

由用户界面主机接收用于交换敏感信息的请求，所述请求从在客户端上被渲染的用户界面被接收，所述请求包括第一访问令牌；

调用所述用户界面以验证所述第一访问令牌和所述请求中提供的其他数据，使用内联框架来调用所述用户界面主机，并且在成功验证时，由所述用户界面主机撷取第二访问令牌用于访问安全区；

使用中级内联框架调用所述安全区内的电子仓库主机，以验证所述第二访问令牌，并且在成功验证所述第二访问令牌时提供对所述安全区内部的内部内联框架的访问；

在所述用户界面中从视线中隐藏所述中级内联框架和所述内联框架；以及

在成功验证所述请求时，通过所述内部内联框架和所述中级内联框架从所述安全区中的所述电子仓库主机接收响应，所述响应包括允许访问用于交换所述敏感信息的用户界面表格的命令，所述响应被转发至所述客户端设备以允许访问所述用户界面表格中的字段，

其中方法操作由一个或多个处理器执行。

11.如权利要求10所述的方法，其中，所述用户界面主机在所述安全区的外部，并且所述电子仓库主机在所述安全区内。

12.如权利要求10所述的方法，其中，所述敏感信息是支付卡信息。

13.如权利要求10所述的方法，其中，所述用户界面通过浏览器被渲染在网络页面上。

14.如权利要求10所述的方法，其中，所述用户界面由本地移动应用渲染。

15.如权利要求10所述的方法，其中，所述用户界面主机是由云服务供应商托管的虚拟服务器。

16.如权利要求10所述的方法，其中，所述电子仓库主机不是虚拟服务器。

17.一种具有在其上定义的程序指令的非暂态计算机可读介质，所述程序指令用于执行接收敏感信息的服务，用户界面被配置为使用所述服务，所述程序指令包括：

用于从由安全区外部的服务器托管的所述用户界面中接收请求的程序指令，所述请求通过第三内联框架、第二内联框架、和第一内联框架被接收，所述第二内联框架在成功验证与所述请求一起接收的访问令牌时被调用，所述第一内联框架在成功验证经由所述第二内联框架接收的安全区访问令牌时被调用，以及

用于在所述用户界面中从视线中隐藏所述第二内联框架和所述第三内联框架的程序指令。

18.如权利要求17所述的非暂态计算机可读介质，其中，所述安全区外部的所述服务器是由云服务供应商托管的虚拟服务器。

19.如权利要求17所述的非暂态计算机可读介质，其中，所述敏感信息包括支付卡信息。

20.如权利要求17所述的非暂态计算机可读介质，其中，用于处理所述请求的程序指令被配置为从本地移动应用或网络浏览器接收所述请求。

21.一种方法，所述方法包括：

接收输入敏感信息的请求，所述请求从在客户端设备上被渲染的网页中被接收，所述请求包括第一访问令牌；

调用用户界面主机来验证所述请求中提供的所述第一访问令牌，所述用户界面主机使用内联框架被调用；

使用所述用户界面主机来验证所述请求中提供的所述第一访问令牌，所述验证使得由所述用户界面主机撷取第二访问令牌用于访问安全区；

使用所述第二访问令牌来调用所述安全区内的电子仓库主机，所述安全区中的所述电子仓库主机被用来验证所述第二访问令牌；

从所述安全区内的所述电子仓库主机接收响应，所述响应包括允许访问用于输入所述敏感信息的所述网页上的一个或多个字段的命令，所述响应被转发至所述客户端设备用于处理，以允许访问所述网页上的所述一个或多个字段，

其中方法操作由一个或多个处理器执行。

22.如权利要求21所述的方法，其中，所述响应通过在所述安全区内被托管的第一内联框架和第二内联框架被提供，所述第一内联框架被嵌套在所述第二内联框架内，所述第一内联框架通过调用所述第二内联框架被访问，其中所述第一内联框架和所述第二内联框架与所述内联框架不同，并且其中所述第二内联框架被嵌套在所述内联框架内。

23.如权利要求22所述的方法，其中，所述第二内联框架和所述内联框架在所述网页上从视线中被隐藏。

24.如权利要求21所述的方法，其中，所述内联框架通过浏览器被渲染为所述网页上的内容。

25.如权利要求21所述的方法，其中，所述内联框架在弹出窗口中被渲染。

26.如权利要求21所述的方法，其中，所述用户界面主机是云服务供应商托管的虚拟服务器或非虚拟服务器中的一个或多个。

27.如权利要求21所述的方法，其中，所述安全区内的所述电子仓库主机包括不是虚拟服务器的一个或多个服务器。

28.如权利要求21所述的方法，其中，所述一个或多个字段是由本地移动应用渲染的用户界面表格的一部分。

29.如权利要求21所述的方法，其中，所述一个或多个字段是通过浏览器被渲染在所述网页上的用户界面表格的一部分。