便于旅行预订支付的系统及方法与流程

本申请相关技术领域是基于计算机系统的旅行预订系统，特别是旅行预订系统，以与不同旅行供应商和服务(包括支付服务)互通并整合其服务。

背景技术：

旅游业涉及大量不同的供应商和旅游产品，涵盖旅行行程的不同方面，例如，包括航班，转机，住宿，租车，旅游，餐券，景点门票等，并涉及多个不同的预订系统。旅行计划通常由旅行社协助，旅行社将协调旅行者的行程和预订，通常通过手动访问各种不同的预订系统。旅行社通常还将促进旅行支付，例如通过接收来自各个供应商的预付款发票或报价，并在合并发票中向旅行者计费。然后，一旦支付了合并发票，旅行社就会向各个供应商分配适当的付款。这通常需要大量的手动调节和处理。

基于互联网的旅行预订系统的最新发展使旅行者(个人和公司)能够更容易地在线计划和预订他们自己的旅行。这种旅行预订系统通常需要使用信用卡预先付款。但旅行费用的某些方面通常是后付费的，例如在住宿结束时支付酒店住宿，用餐和附带费用。公司差旅的成本开销的很大一部分与中央计费账户(无论是公司信用卡还是其他更复杂但类似的解决方案)产生的差旅费用的核对有关。

改进用于促进旅行的不同方面的支付系统是必要的。

技术实现要素：

根据本发明的一个方面，提供一种旅行支付中介系统，其使用计算机处理和存储器资源实现并且被配置为经由通信网络与一个或多个旅行预订系统和一个或多个虚拟信用卡发行系统集成，该系统包括：

旅行预订系统接口，其被配置为与至少一个旅行预订系统通信以获得与至少一个旅行者相关联的旅行预订数据，所述预订数据包括能够识别所述至少一个旅行者的旅行者数据，以及为所述至少一个旅行者定义的一个或多个旅行组件的旅行数据；

预订分析器，其被配置为分析所获得的预订数据，并且针对每个旅行组件，确定与旅行组件相关联的成本组件数据，所述成本组件数据包括旅行组件的虚拟信用卡支付资格；以及

虚拟信用卡(vcc)接口，配置为：

使用旅行组件的成本组件数据生成vcc请求，其中成本组件数据指示vcc支付的资格；

将vcc请求转发给vcc发行系统；

监控对所述vcc发行系统生成的vcc的接收，

接收来自vcc发行系统的vcc，以及

响应于vcc的接收，触发所述分析器将vcc与成本组件数据中的旅行组件相关联，并更新旅行预订系统中的旅行预订数据。

在一实施例中，其中所述预订分析器被配置为对于每个行程项目，将分析规则应用于：

确定所述成本组件是否与所述行程项目相关联，以及

成本组件与所述行程项目相关联的位置：

确定项目价值数据和成本计时数据；

为所述成本组件确定被接受的支付类型以及该行程项目成本组件符合vcc要求时生成vcc请求数据。

在一实施例中，其中所述预订分析器被配置为应用分析规则来为符合vcc资格的成本组件选择vcc供应商。

在一实施例中，其中所述旅行预订系统接口是机器到机器(m2m)接口，被配置为从存储旅行者预订数据的一个或多个全球分销系统中检索旅行数据。

在一实施例中，其中所述旅行预订系统接口m2m接口提供用于与一个或多个gds中的每一个进行通信的标准化接口，该gds使用通用超集应用程序编程接口(api)与一个或多个全球分销系统通信。

在一实施例中，其中所述旅行预订系统接口被配置为周期性地查询一个或多个旅行预订系统中的每一个以检索旅行预订数据。

在一实施例中，其中所述vcc接口是机器对机器(m2m)接口，被配置为利用一个或多个vcc供应商应用程序编程接口(api)并管理vcc的异步请求和接收。

在一实施例中，其中所述vcc接口使用排队系统来管理vcc的异步请求和接收，该排队系统包括至少一个临时数据库，该临时数据库被配置为将每个发送的vcc请求的副本存储在数据库记录中，数据库记录包括vcc请求数据和vcc请求状态，并且其中该数据库记录用vcc详细信息更新，并且响应于从vcc生成器接收vcc详细信息而更新vcc状态。

在一实施例中，还包括通信接口，被配置为将所生成的vcc数据提供给与vcc相关联的旅行组件相关联的目标。

在一实施例中，其中所生成的vcc数据是通过安全通信接口提供的。

在一实施例中，其中所述通信接口被配置为自动地将vcc数据传输到目标。

在一实施例中，其中所述通信接口被配置为提供对vcc数据的受控访问。

在一实施例中，其中所述通信接口被配置为在有限的时间段内提供对vcc数据的访问，该有限的时间段在时间上与为其生成vcc的旅行组件相关联。

本申请另一方面还公开了一种由旅行支付中介系统执行的便于旅行支付的方法该旅行支付中介系统使用计算机处理和存储器资源实现并且被配置为经由通信网络与一个或多个旅行预订系统和一个或多个虚拟信用卡发行系统集成，该方法包括步骤：

通过被配置为与至少一个旅行预订系统通信的旅行预订系统接口获得旅行预订数据，与至少一个旅行者相关联的旅行预订，所述预订数据包括能够识别所述至少一个旅行者的旅行者数据，以及为所述至少一个旅行者定义的一个或多个旅行组件的旅行数据；

通过预订分析器分析所获得的预订数据，以针对每个旅行组件确定与旅行组件相关联的成本组件数据，所述成本组件数据包括旅行组件的虚拟信用卡支付资格；以及

对于每个旅行组件，其中成本组件数据表明vcc支付的资格，虚拟信用卡(vcc)接口执行以下步骤：

使用旅行组件的成本组件数据生成vcc请求；

将vcc请求转发给vcc发行系统；

监控对所述vcc发行系统生成的vcc的接收；

接收来自vcc发行系统的vcc；以及

响应于vcc的接收，触发分析器将vcc与成本组件数据中的旅行组件相关联，并更新旅行预订系统中的旅行预订数据。

附图说明

图1是本发明实施例的旅行支付中介系统的框图；

图2是本发明实施例的系统的示意图；

图3是本发明实施例的分析旅行预订和生成虚拟信用卡的流程图；

图4是本发明实施例的系统的更详细的框图；

图5a是本发明实施例的旅行支付中介系统的旅行预订接口的框图；

图5b是本发明另一实施例的旅行预订接口的框图；

图5c是本发明实施例的旅行支付中介系统的gdsapi功能示意图；

图6a是本发明实施例的旅行支付中介系统的虚拟信用卡管理器接口的框图；

图6b是本发明另一实施例的虚拟信用卡接口的框图；

图6c是本发明实施例的旅行支付中介系统的vccapi功能示意图；

图7是本发明实施例的系统的通知接口的框图；

图8是本发明实施例的与系统的各种队列或临时数据库交互的队列管理器模块的框图；

图9是本发明实施例的与系统的各种数据库交互的数据清理器模块的框图；

图10是本发明实施例的系统的审计日志模块的框图。

具体实施方式

本文描述的系统和方法提供旅行支付中介系统，其被配置为分析旅行预订数据并识别符合虚拟信用卡(vcc)支付条件的行程项目交易，并且对于这些行程项目交易中的每一个，触发生成适当的vcc以影响支付。

虚拟信用卡(vcc)使得能够在支付和旅行(或旅行的组成部分-例如酒店住宿)之间创建1：1匹配。但是，目前使用vcc进行旅行预订的流程要求旅行社手动创建vcc并将其分配给预订(pnr-乘客姓名记录)，或者旅行者使用的在线预订工具(obt)支持创建vcc。前者额外增加了过程的复杂性和不可靠性，从而破坏了vcc的潜在目的。后者需要第三方旅行软件工具来支持个人银行的api，而目前市场上大多数obt都无法使用。

这里公开的旅行支付中介系统和方法有利地在旅行社或旅行者直接创建预订之后自动创建vcc。

参考图1，本发明实施例中提供了一种旅行预订支付中介系统110，其使用计算机处理和存储器资源实现并且被配置为通过通信网络140集成一个或多个旅行预订系统120与一个或多个虚拟信用卡发行系统130。该系统包括旅行预订系统接口112，预订分析器116和虚拟信用卡(vcc)接口114。

旅行预订系统接口110被配置为与至少一个旅行预订系统120通信，该旅行预订系统120用于与至少一个旅行者相关联的旅行预订，并获得该至少一个旅行者的旅行预订数据。预订数据包括能够识别至少一个旅行者的旅行者数据和定义至少一个旅行者的行程的一个或多个旅行组件的旅行数据。预订分析器116被配置为分析所获得的行程数据并针对每个旅行组件确定与旅行组件相关联的成本组件数据。旅行组件的成本组件数据包括旅行组件的虚拟信用卡支付资格。

虚拟信用卡(vcc)接口114被配置为使用用于旅行组件的成本组件数据来生成vcc请求，其中成本组件数据指示vcc支付的资格。vcc引擎将vcc请求转发到vcc发行系统，并监视vcc发行系统生成的vcc的接收。vcc由vcc接口接收，并且作为响应，使得分析器将vcc与成本组件数据中的旅行组件相关联。

这种方法的一个关键优势是，为符合条件的旅行组件分析预订和生成vcc的过程是完全自动化的。此外，预订分析和vcc生成可以配置为在旅行社的系统或他们的在线预订工具系统中非常有效地工作。该系统和方法可以是基于规则的，以实现一致的操作，同时还允许基于更新规则进行直接调整或定制。

该系统可以使用一个或多个网络连接的服务器和数据库形式的计算机处理和存储器资源来实现，这些硬件资源执行软件程序以实现如上所述的功能。或者，计算机处理和存储器资源可以是网络可访问的分布式“基于云”的资源，执行软件以实现如上所述的系统功能。一些实施例还可以利用专用硬件和共享资源的组合。在本发明的范围内可以预期各种不同的系统架构。

旅行预订系统接口112被配置为与用于旅行预订的至少一个全球分销系统(gds)120兼容。所述gds120包括用于搜索，预订和购买产品(例如航班，旅馆，汽车等)的接口和用于存储旅行预订和预订数据的数据库。该系统可以被配置为与许多不同的旅行管理公司和通过在线预订工具使用的多个gds兼容。这种系统在旅游业中是已知的，因此将不详细讨论这种系统的端到端操作或配置。

参考图2，结合本发明的上下文，对旅行预订过程的简要描述。旅行者210通常可以通过电话或面对面在旅行管理公司(tmc)215进行查询和旅行预订，旅行管理公司通常也称为旅行社。tcm旅行社通常将通过gds的代理接口讨论旅行者的计划和查找预订选项，以向gds230查询诸如可用性之类的信息。例如，代理接口可以是在计算机系统上运行的软件应用程序，例如代理的桌面或平板电脑215，具有数据网络连接以实现经由通信网络与gds230的数据通信。在一些情况下，旅行代理系统可以是直接到gds的门户，而不需要中间系统或通信网络。

旅行社收到预订旅行者的请求。旅行社使用预订系统中存储的旅行者资料预订相应目的地的航班，酒店和/或汽车。预订的来源可以是全球分销系统(gds-例如amadeus，sabre，travelport等)，或者可以通过供应商的系统(例如航空公司的专有预订系统，expedia获取酒店内容等)来执行。

或者，用户210可以访问在线预订工具220。在线预订工具通常作为一个或多个gds系统的中介，并提供软件工具以允许用户浏览不同的旅行产品并便于在gds中进行预订。大多数在线预订工具旨在提供传统上由人工旅行社提供的软件服务，并允许旅行者管理他们自己的预订。

通过在线接口220或代理计算机系统215，旅行者数据和预订信息被输入gds230并存储在乘客姓名记录(pnr)中。输入gds230的关键数据是旅行者数据和旅行数据。旅行者信息被视为个人身份信息，因为它包含每个预订的旅行者的直接个人详细信息。此信息可包括全名，联系方式和身份证明文件详细信息(例如，护照，社会安全号码，驾驶执照等)。作为旅行预订(pnr)的一部分，旅行者数据被创建并存储在gds中。旅行信息包含预订的旅行详细信息。此信息本身不包含个人身份信息。作为旅行预订(pnr)的一部分，旅行数据被创建并存储在gds中。

gds还可以存储支付信息的形式，其中可以包括信用卡数据。在旅行业目前使用的手动工作流程中，在预订过程中，旅行社决定使用哪种付款方式进行哪些部分的交易(例如用美国运通商务旅行帐户预定航班，企业信用卡预定酒店，旅行者信用卡预定汽车，用支票付费等)。在这种传统处理中，对于虚拟信用卡(vcc)支付，卡发行系统的vccapi必须集成到旅行社使用的离线预订工具中(通常由他们使用的gds提供)。

相反，在预订过程中，使用所描述的旅行支付中介系统，旅行社不需要决定或采取任何关于使用哪种支付形式的行动，或确定不同类型的付款形式是否可用于交易的不同部分。实施例中所描述的系统，可以由pnr分析器260基于公司策略265来执行对交易的每个部分的支付形式的确定。这样做的一个优点是减少了旅行社所需的工作和性能(无论是人工还是电子，即在线预订工具)。此外，旅行社不需要与金融机构通信以请求vcc。在人工代理的情况下，不需要手动请求vcc。对于代理系统工具(例如专有/私人在线预订工具或人工旅行社使用的离线预订工具)，不需要与金融机构集成以生成vcc。例如，对于虚拟信用卡(vcc)支付，卡发行系统的vccapi275不需要集成到旅行社使用的离线预订工具215中-实施例中的系统中在预订完成后，这可以由vcc接口270提供。这具有显着降低代理系统(即离线预订系统)的集成要求的优点，作为分析预订数据的功能，以确定预订的每个组成部分的支付形式，并通过旅行支付中介系统处理任何vcc的生成。

在另一个例子中，旅行者通过在线预订工具(obt)直接预订航班，酒店和/或汽车。预订的来源可能是gds或第三方系统。在旅游业目前使用的工作流程中，在预订过程中，旅行者可以根据公司的旅行策略，决定使用哪种付款方式来进行交易的哪些部分。对于vcc支付，发卡机构的api必须集成到obt中。

相反，使用所描述的旅行支付中介系统，在预订过程中，旅行者210不需要决定使用哪种支付表格来进行哪些部分的交易-这由pnr分析器基于公司策略265决定260。此外，对于虚拟信用卡(vcc)支付，卡发行系统的vccapi275(对于每个卡发行系统进行交互)不需要集成到旅行者使用的obt220中-预订完成后，这由vcc接口270提供。由于在旅行支付中介系统中实现了支付形式和vcc生成的预订分析，因此不需要在obt220中实现或维护该功能。

本系统的一个优点是用于生成vcc的过程是自动化的。支付数据的形式可以由系统自动生成并添加到存储在gds中的pnr中。

图2中示出了实施例中旅行预订系统接口240的示例。系统240作为gds230和金融机构系统275之间的中介进行操作，以自动请求和随后处理vcc以进行旅行预订。在图2所示的实施例中，gds的接口由pnr读取器250和pnr写入器255提供。图3的流程图还示出了系统功能的具体示例，其示出了用于基于来自gds的旅行预订数据自动生成vcc的主要步骤300。

pnr读取器250被配置为从pnr读取数据，例如，从gds310下载预订(由代理或旅行者做出)。该系统包括pnr分析器260，其配置成分析下载的pnr预订数据以确定任何一个或多个旅行组件是否具有相关联的成本组件。该实施例中的pnr分析器是分析器，其应用存储在存储器265中的分析和策略规则268以首先分析所检索的预订数据以识别各个旅行组件315，然后针对每个旅行组件320确定是否存在相关联的成本组件325以及成本组件是否有资格获得vcc支付330。在一个实施例中，如果分析确定所有的成本组件适合于虚拟信用卡的应用，则系统可以触发vcc的生成。系统可以配置为根据公司策略规则中配置的客户端首选项自动触发符合条件的旅行组件的vcc生成。公司策略可以指定使用vcc支付哪些旅行组件。可选地，在一些实施例中，还可以允许旅行社重写支付形式。

vcc接口270通过与金融机构系统275集成来生成vcc。例如，vcc接口通过安全机器到机器接口准备并转发vcc请求340到金融机构系统275。vcc接口随后从金融机构系统接收生成的vcc350。一旦接收到生成的vcc，该vcc号就可以与pnr数据库中的成本组件360相关联。存储在gds上的预订可以通过pnr写入器255的付款方式(fop)详细信息更新370。支付数据的形式由系统生成并添加到预订信息中。该信息可用于下游支付处理(例如，用于机票)和/或发送给第三方以针对以后的(例如，用于酒店住宿)收费。该系统还可以被配置为例如经由安全通信接口或点对点通信(例如通信到的酒店传真285)直接向商家(例如酒店)通知预订应该被收取的vcc号码。

现在将参考图4更详细地讨论系统架构和操作。图4示出了实施例的旅行支付中介系统400，示例的示出了用于实现系统架构的旅行预订接口410，预订分析器420，vcc管理接口430和可选的通信接口440。这里讨论的实施例提供了关于系统的实际实现的更多细节。

在该实施例中，旅行预订接口410包括gds应用程序编程接口(gdsapi)412，pnr读取器414，pnr数据库416和pnr写入器418。如上所述，作为旅行预订(pnr-乘客姓名记录)的一部分，旅行者数据被创建并存储在gds中。离线和在线预订(pnr-乘客姓名记录)存储在旅行管理公司(tmc)使用的gds中。参考图4，pnr读取器414和pnr写入器418都被配置用于经由gdsapi412与gds数据库接口450进行机器到机器的通信。

pnr读取器414被配置为从gds检索这些预订的预订数据并将它们存储在pnr数据库416中以进行分析。pnr读取器414可以被配置为生成周期性或触发的预订数据检索请求。pnr阅读器也可以由gds触发。

pnr写入器418被配置为经由gds数据库接口450更新存储在gds中的pnr中的数据。

gds230包括gds数据库接口450，以实现与gds的交互以及读取和写入gds数据库的信息。例如，每个gds数据库接口450可以提供用于检索和更新存储在gds230中的预订的api(应用程序处理接口)。

在当前的商业旅行系统中，每个不同的gds230具有其自己的特定和专有api。当需要与多种类型的gds系统交互时则产生了兼容性问题，例如，需要支持每个专有api。

在本实施例的旅行预订支付中介系统中，通过提供中介系统gdsapi412来解决该问题。中介系统gdsapi412是通用超集api组件，其提供用于经由每个gds数据库接口450与不同gds通信的标准化接口。

每个gds都提供用于交换数据的机器到机器接口。这些接口之间在连接性，认证，数据结构和读取与写入数据的方法方面的差异是显着的，并且这些接口经常改变(例如，以迎合新型旅行产品)。如果没有中介系统gdsapi412，则需要将这些差异分别编码到每个组件(pnr读取器和pnr写入器)中并持续维护。中介系统gdsapi412抽象出所有差异，并提供有效的变更和扩展，以支持仅需要在一个组件中维护的附加gds：gdsapi412。

图5a示出了本中介系统的体系结构，包括gds接口450(用于任何一种或多种不同类型的gds450a-f)，gdsapi412，pnr读取器414和pnr数据库416。图5b示出了另一实施例中在没有gdsapi412的情况下体系结构，其中需要为写入pnr数据库416的每个gds450a-f单独的创建和维护pnr读取器或预订读取器组件510,520,530,540,550,560。(例如amadeus540a，sabre540b，travelport540c等)或伪gds(例如expedia450d，hrs450e，lido450f等)。另外，需要创建pnr格式化器570，其将从伪gds540d-f数据库中进行预订并且将它们一致地格式化为gds系统通常如何构造行程数据的格式。相反，在本系统中(如图5a所示)，gdsapi412被配置为与任何gds接口450a-f，gds或伪gds接口，以为pnr读取器414和pnr写入器416提供通用(或gds无关的)接口。

gdsapi412使用从pnr阅读器和pnr写入器角度提供标准操作(例如写入和编辑)的协议或体系结构来实现，并且gdsapi用于将标准操作转换成适合于每个gds的消息格式。gdsapi功能如图5c所示，pnr读取器414和pnr写入器418使用与gds无关的公共消息格式，以通过gdsapi请求标准gds操作(即，写入和编辑)。gdsapi412中的转换功能585将请求转换为适合于目标gds的消息格式590a-n。类似地，gds返回消息的特定格式590a-n被转换585到pnr读取器和pnr写入器的公共格式消息580中。例如，为了获得pnr读取器输入到gdsapi提供者数据(即旅行代理gds的url)的pnr记录数据，gdsapi412使用该提供者数据来格式化消息并将消息指引到适当的gds接口。消息由gds接口解析，并触发gds接口内部操作以返回gds数据库中的数据表示。返回的消息由gdsapi接收，并且由转换功能585从消息中提取数据，并由gdsapi以通用格式580返回到pnr阅读器。转换功能585被配置用于每个标准操作请求，以使用来自公共格式请求的数据来填充gds特定格式的模板请求，以便转发到gds数据库接口。来自gds的返回数据以gds特定格式接收，类似地用于填充公共格式模板消息以转发到pnr读取器或pnr写入器。因此，从pnr读取器和prn写入器的角度来看，通用的gdsapi用于不同配置的gds或伪gds系统。在所述实施例中，从发送请求的步骤中抽象出请求控制，因此该处理对于所有gds是通用的，并且在gdsapi和pnr读取器与pnr写入器之间以公共格式580处理。因此，只有gdsapi处理消息发送/接收才需要特定于gds。从系统的角度来看，这具有请求以gds无关的方式处理的优点。为了便于添加新的gds，唯一需要的修改是gdsapi添加适当的信号格式。

在一个实施例中，gdsapi412可以实现为具有json数据对象和oauth2.0认证的restapi。

可以通过gdsapi412提供以下功能：

pnr读取器414被配置为从gds检索预订并将这些预订存储在pnr数据库416中。将预订数据的副本存储在与gds数据库分开的本地数据库中进行分析具有减少对gds的查询数量和gds数据完整性风险的优势。

pnr读取器412被配置为经由gdsapi和相应的gds数据库接口450自动连接到gds以检索预订。该自动连接可以是周期性的，其频率和间隔可在系统中配置。在一些实施例中，预订检索频率可以针对每个不同的gds进行配置。例如，对于一个gds系统，pnr读取器可以被配置为执行批量检索和处理预订数据，例如每天一次或两次，对于另一个gds系统，pnr读取器可以被配置为每30分钟检索和处理预订数据，对于另一个gds，下载频率可能是每分钟，或者，在一些实施例中，gds可以触发预订检索。在一些实施例中还可以提供手动触发的预订检索-例如，使旅行社能够触发系统检索预订数据，并生成vcc，而不是等待定期或批量处理。例如，gds可以被配置为经由gds接口和gdsapi412将pnr数据推送到pnr读取器414。或者，gds可以被配置为经由gdsapi向pnr发送触发以使pnr读取器使用如上所述的过程来检索pnr数据。

在图4的系统的实施例中，pnr读取器组件412使用为每个tmc配置的凭证以频繁规律的间隔连接到gds450，并从配置的预订队列中检索任何预订(pnr)。然后将下载的pnr存储在pnr数据库416中。

pnr数据库416存储它从pnr读取器414接收的pnr，并使它们可用于pnr分析器组件422。

pnr数据库可包含以下信息：

在系统的优选实施例中，pnr数据库416中的预订数据被加密存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的gdsid相对应。

pnr数据库416本身可以在文件级别上进一步加密(例如，tde-用于微软sql的透明数据库加密)。这可以提供附加的数据安全性。

预订分析器420包括pnr分析器422，在图4的实施例中，pnr分析器被处理引擎实现，其被配置为应用规则数据库424中定义的规则。pnr分析器422处理pnr并根据公司策略数据库424中的公司规则对其进行检查。

处理引擎和基于规则实现的优点在于可以将基本处理功能编程到分析器中，并且使用规则容易改变情境操作。这使得能够定制分析规则以根据策略或实践变化以及管辖变化来改变系统操作。例如，如果提供新类型的旅行产品(例如，新型交通或住宿产品)，则可以利用规则来定义识别不同类型旅行产品的标准，然后定义识别标准的新规则和vcc资格可以作为新规则或规则修改引入进入统中。策略管理器组件426提供用于查看和编辑存储在公司策略数据库424中的策略和规则的接口。

如果可用的话，公司策略数据库424存储为每个tmc的每个客户端配置的公司策略数据。每个客户的公司策略数据定义了应用于分析该客户的旅行预订的一组(或多组)设置。应当理解，这还允许客户端特定的更新其规则设置。

公司策略将包括至少两种类型的规则。第一类规则涉及分析pnr记录数据，以识别产生vcc所需的pnr记录中的数据，并确定整个预订的资格(即真或假)和/或为vcc处理的个别旅行组件。第二类规则涉及生成新pnr记录数据，特别是用于分析提取的和分类的pnr记录数据以控制用于生成支付数据形式的参数以添加到pnr数据，包括vcc的生成。

公司策略数据库424包含以下信息：

公司策略数据库中的公司策略可以加密存储，因为它可能包含付款方式匹配的未屏蔽/可读信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的客户端id相对应。

公司策略数据库本身可以在文件级别进一步加密(例如，tde-微软sql的透明数据库加密)。

pnr分析器可以配置为频繁规律的间隔的检查pnr数据库，以查找尚未处理的pnr。或者，可以响应于pnr读取器414将新的pnr数据输入数据库来触发pnr分析器422。

pnr分析器422处理每个pnr以提取相关数据。在示例中，pnr分析器422处理每个pnr以提取以下信息：

公司数据

旅行者数据

旅行数据(航班，酒店，汽车)

付款数据形式

pnr分析器检查pnr中的公司数据信息，并从公司策略数据库组件中检索相关的公司策略。如果pnr分析器与公司数据不匹配(即公司没有配置的公司策略)，则它会将pnr数据库中的状态更新为排队(由pnr写入器处理)。

pnr分析器422使用公司策略424中的规则来尝试将其与pnr中的旅行者和行程数据进行匹配，以提取和分类pnr数据。规则可能包括：

旅行者姓名(例如，与特定姓名匹配)

旅行者职位(例如，与特定职位或包含特定单词的特定职位匹配，例如“经理”)

旅行者工作状态(例如匹配“承包商”或“访客”等状态)

旅行者vip状态(例如，如果旅行者被标记为“vip”，则匹配)

旅行者成本中心(例如，与特定成本中心代码或代码的一部分匹配)

旅行者项目代码(例如，与特定项目代码或代码的一部分匹配)

旅行者位置(例如，与办公地点匹配)

旅行者数量(例如，旅行中的旅行者人数)

航空公司名称(例如，与特定航空公司匹配)

航空公司票价等级(例如，与“j/商务舱”等特定票价类型匹配)

航空公司票价(例如，与范围内的票价价值匹配)

航空公司航班地点(例如，入境或出境航班的匹配地点，包括国内，区域或国际旅行)

酒店名称(例如，与特定名称或包含特定单词的特定名称匹配，如“希尔顿”)

酒店位置(例如，与特定城市或国家/地区匹配)

酒店价格(例如，与范围内的酒店住宿价格匹配)

租车名称(例如，与特定名称或包含特定字词的特定名称匹配，例如“hertz”)

租车地点(例如，与特定城市或国家/地区匹配)

租车等级(例如，匹配特定类别类型，如“紧凑”)

租车价格(例如，与范围内的汽车租赁价格匹配)

付款方式(例如，如果fop为空白或与特定fop匹配，如公司信用卡号码模式)

旅行持续时间(例如，与旅程持续时间或范围内的旅程持续时间匹配)

旅行日期(例如，匹配“今天”与旅行发生日期之间的差异)

应当理解，该列表并非详尽无遗，并且可以定义规则的任何组合，并且将在实施例之间变化。

还为pnr分析器定义了公司策略中的规则，以评估vcc资格，生成fop数据和控制生成的vcc。

公司策略中的规则可以与标准布尔运算符(and，not，or)，比较运算符(＝，<>，>，>＝，<，<＝)组合，并且可以使用字符串匹配符号(例如“*”)。公司策略中的规则按其编写顺序进行评估。

例如，对于公司旅行者的公司策略，公司是旅行社的客户，规则可以包括：

使用航班段的公司vcc，如果

旅行者工作状态是“承包商”and

航空公司航班位置是“国内”

使用汽车段的公司vcc，如果

旅行者vip状态为“否”and

租车名称为“*hertz*”

使用所有旅行段公司vcc，如果

(旅行者项目代码是“6-2*”and

旅行者vip状态不是“否”)or

(旅行者数量>2and

旅行时间>＝3)

使用酒店段的tmcvcc，如果

酒店价格>＝200

例如，对于休闲旅行者的公司策略，旅行者是旅行社的客户，规则可以包括：

使用所有旅行段的tmcvcc，如果

(付款方式为nullor

旅行日期>100)or

(航空公司的航班位置是“国际”and

航空公司名称为“qantas”and

航空公司票价<2000)

如果pnr分析器422将pnr中的数据与公司策略中的规则匹配，则它然后向vcc创建器432发送vcc请求并将pnr数据库416中的状态更新为请求。应当理解，分析一个预订的pnr数据可能导致多个vcc请求，因为可以为每个合格的旅行组件生成单独的vcc请求。

如果pnr分析器422与pnr中的数据与公司策略中的规则不匹配，则它将pnr数据库416中的状态更新为排队(也就是：放入队列以便由pnr写入器418处理以返回到gds)。

pnr写入器418以频繁规律的间隔检查pnr数据库416以查找已排队的pnr。它使用为该预订tmc配置的凭证连接到gds，并将更新的pnr发送到gds。如果成功，则将状态更新为已交付(意味着：成功传送到gds，因此不需要pnr写入器418进一步处理)。如果不成功，则将状态更新为失败(意味着：未成功传送到gds，因此由pnr写入器418重新尝试或通过排队管理器作为错误通知)。

现在将更详细地讨论vcc管理器430。vcc管理器包括vcc创建器432，vcc队列434，vcc接口436和vccapi438，用于与vcc发行系统接口460(例如金融机构或信用卡服务提供商)交互。

如果需要vcc，由pnr分析器根据相关规则确定，则vcc请求被发送到vcc创建器以生成虚拟信用卡。

在该实施例中，用于生成vcc的金融机构的选择是规则驱动的(例如，被定义为pnr分析器应用的公司策略的一部分)。通常，旅行社将与vcc发行系统(例如，amex)进行安排。客户/旅行者可能会与信用卡发行系统达成协议，例如美国证券交易所(amex)和anz维萨(visa)。规则定义了将vcc请求发送给不同金融机构的情况。例如，对于航班，规则可以定义系统将使用旅行社的amex账户来生成vcc(旅行社随后将在发票上向客户开具账单)。另一条规则可能规定，对于酒店住宿，系统将使用客户的美国运通安排，而对于汽车租赁，它将使用客户的anzvisa安排。

pnr分析器可以在vcc请求中包括要传递给vcc创建器432的数据：vcc的金融机构；vcc数量(可以是上限或精确值)；和旅行组件的日期，用于设置vcc的到期日期。该数据在vcc请求中提供给vcc创建者。

vcc创建器432从pnr分析器422接收vcc请求，并且它将请求存储在vcc队列434上。vcc请求是异步过程，其中请求由中介系统发送到外部vcc生成器(即金融机构)，并且在发送vcc生成请求和接收生成的vcc详细信息之间通常存在延迟。在系统的优选实施例中，通过在短期数据库中存储转发请求的详细信息来管理该处理延迟，该短期数据库在图4中称为vcc队列，用于与接收的vcc进行协调。该系统还能够处理“丢失的”vcc请求，其中没有接收到响应于vcc生成请求答复-例如，在通信网络故障的情况下，或者在vcc发行系统处的系统错误。可以检查队列，例如每3到5秒检查一次，以识别尚未收到vcc响应的转发vcc生成请求。

其他实施例可以不使用队列，并且vcc接口直接与vcc创建器通信以识别vcc何时被创建(或失败)。然而，在该实施例中，监视待处理请求的状态是有问题的。例如，因为这将需要向卡发行系统接口发送额外信令，检查待处理请求的状态变得更加困难。因为队列管理器可以检查队列的状态，并且可以根据队列中的状态设置通知(例如，未在3分钟内处理vcc请求发送警报)，无需与金融机构的vcc创建器进行额外的联系，建议的队列或短期数据库实施更容易。

在一个实施例中，pnr分析器发送给vcc创建器的vcc请求是json格式的，发送到restapi。

vcc请求包含以下详细信息：

由vcc创建器接收的vcc请求存储在vcc队列.中。

vcc队列由以下部分组成：

vcc队列中的vcc信息可以加密存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的vccid相对应。

vcc队列本身可以在文件级别进一步加密(例如，tde-微软sql的透明数据库加密)。

vcc接口436以频繁规律的间隔检查vcc队列。它配置为检索所有尚未处理的请求。vcc接口436将它们发送到vccapi438以生成vcc并将状态更新为排队。

如果来自vccapi438的响应不成功，则vcc接口436将请求的状态更新为失败。

如果来自vccapi438的响应成功，则vcc接口436将使用vcc细节更新vcc队列并将请求的状态更新为已交付。

每个发行系统(即金融机构)都有自己独特的专有api来生成vcc。系统vccapi438是通用超集api，它提供了用于生成vcc的标准化接口。如果没有中介系统vccapi438，则需要将这些差异分别编码到每个金融机构的每个组件中，并持续进行维护。中介系统vccapi438提取所有差异并提供有效的改变和扩展以支持其他金融机构，并允许vccapi438作为模块化的机器到机器接口被许可至其他机构。

图6a示出了本实施例中介系统的体系结构，包括vcc队列434，vcc接口436，vccapi438和卡发行系统接口460(所有的一个或多个不同的卡服务提供商/金融机构460a-e)。图6b示出了其他实施例在没有vccapi438的情况下的体系结构，其中需要为每个金融机构460a-e创建和维护单独的vcc接口610,620,630,640,650(例如，德国嘉惠(airplus)460a，美国运通公司(americaexpress)460b，大来卡(diners)460c，万事达(mastercard)460d，维萨(visa)460e等)。相反，在本实施例的系统中(如图6a所示)，vccapi438被配置为与任何金融机构460a-e接口，以使vcc接口436成为通用的(或与金融机构/vcc发行系统无关的)。与如上所述的gdsapi的实现类似，vccapi438使用协议或体系结构来实现，该协议或体系结构从vcc接口436提供透视标准操作，使用通用格式经由vccapi438发送到所有vcc发行系统。如图6c所示，vccapi438提供转换功能670以将公共格式消息660转换为特定卡发行系统消息格式690a-n，使其能够转发由各个vcc发行系统接口解析的自描述消息以触发vcc生成。相应vcc发行系统接口的返回数据被vccapi类似地转换为公共消息格式。这具有以下优点：处理来自vcc接口的vcc请求独立于实际vcc系统。为了使系统能够容纳新的vcc发行系统，仅需要更新vccapi以将转换添加到新的信令格式中。

在一个实施例中，vccapi被具有json数据和oauth2.0认证的restapi实现。

vccapi:提供以下功能

当成功生成vcc(状态更新为已递送)时，vcc创建器432可以向通知网关442发送通知消息并更新pnr数据库416中的pnr以供pnr写入器418处理。pnr更新为vcc详细信息(付款方式详细信息)和已交付状态，以便pnr写入器在gds中进行更新。具有支付形式(fop)信息的更新的pnr然后由pnr写入器418经由gdsapi412发送回gds。因此，支付中介系统用生成的vcc数据进行自动更新gds操作。gds还可以用分析期间产生的其他形式的支付数据来更新，例如指定旅行者根据公司策略规则应支付的旅行组件。

该系统的实施例可以包括通信或通知接口440，其被配置为将用于预订的vcc细节安全地传送给各方以处理对旅行组件的付款。通信接口440包括通知网关442，通知队列444和通知组件470以适应一种或多种通信技术。

一些实施例的特别有利的特征是自动管理给旅行交易各方的支付数据。为了提供背景信息，我们将讨论一些旅行预订方案和相关付款。一些旅行组件通常是预付费的，例如航班。传统上对于航班而言，付款详细信息记录在pnr中，例如，信用卡(cc)详细信息。航空公司在签发机票时，会使用这些详细信息向cc收取费用并完成付款交易。但是，根据使用的cc详细信息，对帐可能存在付款问题。

但是，对于其他旅行组件，例如酒店和汽车，付款的处理方式不同。这些服务可以在旅行后支付或旅行时支付，而不是像航班那样预付。通常情况下，酒店和汽车在预订时不会通过信用卡收费(例外情况是预付酒店住宿，但这通常不用于公司旅行)。酒店或汽车租赁公司仅在旅行者退房后/退还汽车后才通过当时由旅行者提供给他们的信用卡收费，或者通过旅行社以其他方式与他们联系。

例如，对于酒店而言，公司旅行通常有三种情景(这些情景也适用于其他旅行组件)：

1)旅行者将向酒店提供个人信用卡，然后要求雇主报销。

2)旅行者将向酒店提供他们的公司信用卡，然后必须进行费用报告以匹配旅行细节等。或者公司可能有一个中心功能为每个人做这件事。

3)旅行社将向酒店发送一份传真，上面写着“约翰史密斯将在下列的日期入住您的酒店-当他退房时，请使用我们下列信用卡收取该房费”，然后该中介需协调这些并将发票发送给他们为那些这样做过的各种公司。2)和3)是最常见的情况。

这些传统方法是有效的，但有两个问题：

1.安全性-特别是对于上述3)，相同的信用卡号码被发送到全国/世界各地的多家酒店，有时也会发给旅行者，增加了欺诈风险；

2.对账-相同的信用卡号码(无论是旅行社还是旅行者的公司卡)用于多次旅行和旅行组件，使得信用卡交易与旅行细节相匹配非常困难。如果信用卡交易日期与旅行日期不完全匹配，则这可能特别成问题。这可能是一个常见的问题。例如，酒店可能仅在出账后几天向信用卡收费，并且一些(通常是小型)酒店仅每周处理一次或两次付款，例如当使用兼职簿记员时。此外，信用卡收取的金额很少与预订中指定的金额相符。例如，玛丽可能已经使用过迷你吧，马克可能在返回汽车之前没有装满汽油，因此会产生额外的费用。因此，很难在一张公司信用卡上核对大量付款。

vcc通过在交易和旅行组件之间提供1：1匹配来解决上面讨论的两个问题。问题是这些vcc详细信息需要在办理登记手续时(提交押金)和退房时(最终入住账单)与酒店/汽车租赁场所进行实际通信。在旅行预订和进行旅行之间可能有相当长的一段时间。

在支付中介系统的实施例中，实施通知过程以管理vcc数据到供应商的通信。通知系统获取vcc详细信息并在正确的时间将这些信息发送(例如传真)到酒店等。vcc数据也可以提供给旅行者，例如通过app应用程序。例如，app可以被配置为显示vcc的生成照片。可选的，app可以与数字钱包系统集成，或采用近场通信(nfc)以在销售时(例如，苹果支付(applepay))传送vcc详细信息以在旅行时直接支付旅行组件。

图5中示出了通知接口的实施例的更详细的概述。如果vcc创建成功，则vcc创建器432将生成被发送到通知网关442的通知消息。通知网关442将接收通知消息并通过配置的通知信道发送它，例如如图5所示。

vcc创建器432向通知网关442发送通知消息，通知网关442将其存储在主通知队列444上。

通知网关442可以被配置为以频繁规律的间隔检查主通知队列444。通知网关442检索来自主通知队列444的尚未处理的将要处理的所有消息(调度时间<当前时间)。

在一个实施例中，通知接口实现多个队列，每个队列与一种通知技术类型相关联，例如传真，电子邮件和在线数据通信方法。

通知网关442读取目标类型并将消息发送到适当的{目标}通知队列：

目标类型:传真→传真通知队列705

目标类型:电话→在线通知队列715

目标类型:电子邮件→电子邮件通知队列710

目标类型:万维网→在线通知队列715

目标类型:应用程序→在线通知队列715

当消息已成功排队到适当的{目标}通知队列时，通知网关442将主通知队列444上的通知消息的状态更新为排队。

在一实施例中，由vcc创建器432发送到通知网关的通知消息是json格式的对象，发送到restapi。

通知消息包含以下详细信息：

通知消息中的vcc和消息正文信息优选地被加密存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的vccid相对应。

通知网关收到的通知消息存储在主通知队列中。

主要通知队列可由以下部分组成：

主通知队列中的通知消息以加密方式存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的vccid相对应。

主要通知队列本身在文件级别上进一步加密(例如，tde-微软sql的透明数据库加密)。

通知网关442以频繁规律的间隔检查主通知队列444。它检索所有尚未处理的消息(计划时间<当前时间)。根据目标类型，它将它们发送到相应的{目标}通知队列，并将状态更新为已排队。在所述示例中，目标队列包括传真通知队列705，电子邮件通知队列710和在线通知队列715。这些网关中的每一个都由相应的网关周期性地查询，然后通过相关的通信信道处理并适当地发送通知。在所述的示例中，所提供的网关是传真网关720，电子邮件网关725和在线网关730。在所述实施例中，在线网关被配置为处理基于万维网，电话和应用程序的消息传递，例如推送通知或应用特定数据信令。然而，在一些实施例中，可以使用各个队列和相应的网关。

{目标}通知队列(每个目标类型分列一个)包含以下部分：

{目标}通知队列中的消息正文以加密方式存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密方式对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的vccid相对应。

{目标}通知队列本身在文件级别上进一步加密(例如，tde-微软sql的透明数据库加密)。

通知组件具有用于内部通信和与其他组件通信的api。

在一个实施例中，通知api是具有json数据和oauth2.0认证的restapi。

通过api提供以下功能：

传真网关720以频繁规律的间隔检查传真通知队列705。它检索所有尚未处理的消息(计划时间<当前时间)。

该组件将未处理到排队的通知消息的状态更新，然后将消息标题，消息正文和消息页脚组合到一个消息页面中。

然后，传真网关720将读取目标传真号码并通过传真接口发送消息。传真接口尝试通过与pstn或isdn硬件连接将传真发送到目的地。成功交付记录为已交付。在配置的间隔后重新尝试不成功的交付(忙，无应答，失败)。如果尝试设置的次数后仍然不成功，则将它们记录为失败。

传真网关720将更新从排队处理到已递送或失败的通知消息的状态。

电子邮件网关725以频繁规律的间隔检查电子邮件通知队列710。它检索所有尚未处理的消息(计划时间<当前时间)。

该组件将未处理到排队处理的通知消息的状态更新，然后将消息标题，消息正文和消息页脚组合到一个消息页面中。

然后，邮件网关725将读取目标电子邮件地址并将消息发送到电子邮件接口。

电子邮件接口尝试通过smtp和ssl/tls的网络连接将电子邮件发送到目标地址。成功交付记录为已交付。

在配置的间隔后重新尝试不成功的交付(非永久性故障)。如果尝试设置的次数后仍然不成功，则将它们记录为失败。

电子邮件网关725将更新从排队处理到已发送或已失败的通知消息的状态。

在线网关组件730以频繁规律的间隔检查在线通知队列715。它检索所有尚未处理的消息(计划时间<当前时间)。

该组件将未处理到排队处理的通知消息的状态更新，然后将消息标题，消息正文和消息页脚组合到一个消息页面中。

然后，在线网关730将读取目标电子邮件地址或旅行者电子邮件地址作为唯一用户名标识符，其可用于请求或路由通知并将消息发送到在线数据库组件735。应当理解，对于在线通知，可以响应于对通知(接收)的请求而不是将其转发到目的地(推送)来接收这些通知。例如，目标软件应用程序可以查询系统以从在线数据库检索通知，而不是直接传输这些通知，如传真通信的情况。

在线网关730以频繁规律的间隔检查在线数据库735组件以查找排队的通知消息的状态。该组件将更细处理为已传递的通知消息的状态。

在线数据库735存储它从在线网关730接收的通知消息。通过在线api，它然后使其可用于万维网网关745，电话网关755和应用程序网关750。

在线数据库包含以下信息：

在线数据库735中的通知消息被加密存储，因为它包含未屏蔽/可读的信用卡数据。使用对称密钥加密对数据进行加密，密钥存储在密钥保管库(例如azure密钥保管库)中，与特定的通知id相对应。

在线数据库本身在文件级别进一步加密(例如，tde-微软sql的透明数据库加密)。

在一实施例中，在线数据库api740是具有json数据对象和oauth2.0认证的restapi。

在线数据库api740提供机器到机器接口以允许在线系统访问在线数据库735中的通知。这允许通过在线数据库api740灵活地将系统与各种外部在线系统集成。任何外部系统可以被配置为利用在线数据库api740。与上面针对gdsapi和vccapi所描述的类似，在线api使用提供标准操作的协议或体系结构来实现，以使得能够转发由相应的外部在线系统和触发通知来解析的自描述消息。通过在线数据库api740提供以下功能：

在验证认证并处理获取消息请求之后，组件740将从密钥保管库请求该消息的密钥，解密该消息并发送解密的消息内容作为对该请求的响应并将该消息的状态更新为已发送。

访问在线数据库735的认证可以通过以下一个或多个来执行：

用户名和密码

一次性密码

一次性限时代码

万维网网关745组件是用于认证对在线数据库735的访问并且向请求它的用户提供通知消息(即，虚拟卡详细信息)的网站。

系统可以被配置为限制通知消息可供访问的时间。例如，系统可以配置为使用时间窗口访问vcc详细信息的通知，该时间窗口暂时链接到供应商需要vcc详细信息的时间段，以影响所需支付的服务。通知消息仅在“旅行时间”之后以及配置的时间长度内可用，之后将不再可用。例如，对于为支付酒店住宿而生成的vcc，可以将访问窗口安排在预订当天(或之前一天或两天)打开并在预定结账日期之后关闭一周。该访问窗口可以使用规则进行配置，并且可以针对不同的旅行组件类型(即，用于酒店住宿，租车，旅行等的不同时间窗口)而变化，并且可以在实现的不同系统之间变化。

电话网关组件755是ivr应用程序，用于验证对在线数据库735的访问，并向请求它的呼叫者提供通知消息(即虚拟卡详细信息)。

通知消息仅在“旅行时间”之后以及配置的时间长度内可用，之后将不再可用。

应用程序网关组件750可以是旅行者的伴侣app，用于验证对在线数据库735的访问并向用户提供通知消息(即虚拟卡详细信息)。

通知消息仅在“旅行时间”之后以及配置的时间长度内可用，之后将不再可用。

在系统的一些实施例中，可以通过如图6所示的队列管理器组件来管理维护各种临时数据库/队列和监视队列的完整性。队列管理器810被配置为允许监视队列的交易行为并且基于有限的队列数据访问。队列管理器810提供查看vcc队列432，主通知队列444和{目标}通知队列705,710,715,735并对队列中的项目执行直接动作的能力。

对于每个队列，队列管理器810可以查看：

通知id

vccid

旅行社id

客户id

gdsid

旅行者详细信息

目标id

目标类型

目标联络方式

旅行时间

状态

队列管理器810不能用于查看vcc的详细信息(即信用卡号)。

对于队列中的每个通知消息，队列管理器810可以重新发送或删除消息，但不能编辑消息。

数据安全性是系统的一个重要方面，特别是当系统存储个人身份和财务信息时。以下是流经系统的主要数据类型：支付数据，旅行者数据和旅行数据的形式。付款信息表格涵盖系统处理的每个预订的信用卡数据。此信息包括信用卡名称，编号，到期日期和cvv详细信息。旅行者信息被视为个人身份信息，因为它包含系统处理的每个预订的旅行者的直接个人详细信息。此信息包括全名，联系方式和标识身份证明文件详细信息等数据。旅行信息包含通过系统处理的预订的旅行详细信息。此信息本身不包含个人身份信息。

支付形式数据可以由系统生成，添加到预订信息中以用于下游支付处理(例如，用于机票门票)和/或发送给第三方以在稍后的日期(例如，用于酒店住宿)收费。vcc创建器组件在vcc队列中生成vcc请求消息。vcc接口组件通过vccapi生成虚拟信用卡详细信息并将其保存在vcc队列中。

vcc创建器使用vcc队列上生成的vcc详细信息来更新pnr数据库中的预订和/或通过通知网关组件通知商家。

维护数据安全性对系统很重要。该系统包含两种类型的机密数据：

个人身份信息-与旅行者有关；以及

信用卡数据-与虚拟信用卡相关。

与旅行者相关的个人身份信息包括全名，联系方式和身份证明文件详细信息等数据。信用卡数据包括信用卡名称，编号，到期日期和cvv详细信息。

这两种类型的数据都通过系统的几乎所有组件传递，并存储在以下组件中：

pnr数据库

vcc队列

主要通知队列

目标通知队列

在线数据库

一些实施例旨在使用加密数据存储来维护安全性和数据完整性。数据存储在系统和文件级别通过使用内置操作系统和数据库系统工具(例如tde-微软sql的透明数据库加密)进行加密。

这些数据存储中的信用卡数据通过使用对称密钥加密在现场级加密存储。每个单独数据字段的密钥存储在独立安全密钥保管库(例如，azure密钥保管库)中，针对该数据存储中该字段的特定标识符(例如，vcc队列中的vccid)。

实施例中还可以被配置为通过ssl/tls协议以加密形式在组件之间传输数据。在可能的情况下，带有外部组件的数据以加密形式(ssl/tls)或通过点对点通信信道(例如传真)传输。

系统的一些实施例中可以包括用于维护数据完整性和数据安全性的数据清理器组件，其示例在图7中示出。数据清理器910以规则的间隔通过队列和数据库，并清除(掩盖)所有被认为过时的信用卡数据。例如，如果vcc的到期日期超过当前日期，或者旅行的最后日期是超过当前日期的配置时间间隔，则可以假定vcc现在已过时。例如，数据清理器810可以配置为屏蔽过时的信用卡和vcc数据：

pnr数据库416

vcc队列432

主要通知队列444

目标通知队列705,710,715

在线数据库735

vcc系统还可以配置为提供由所有组件生成的所有审计消息的集中式安全存储库。在一个实施例中，这被审计日志子系统实现，如图8所示。

审计日志1000包括审计数据库1010和审计api1020，其由系统的各系统组件1030调用以发送审计消息。例如，数据库1010可以被配置为存储多个审计日志，存储用于各系统组件1030的审计消息，即pnr分析器422，pnr读取器418，pnr写入器414，vcc创建器432，vcc接口436，通知。在优选实施例中，为了维护数据的完整性，审计api1020不能删除存储在日志1010中的任何消息。此外，还可以将所有审计消息复制到单独的只读(仅输入)系统。

审计数据库1010在文件级别上加密(例如，tde-用于微软通信。它不存储任何未屏蔽的信用卡数据。

审计数据库1010包含以下信息：

审计api提供以下功能：

应当理解，如上所述的系统提供了安全接口系统，以便于虚拟信用卡的自动生成以及vcc与旅行组件相关联，这样可以传送vcc详细信息以影响相关旅行组件的付款。这使得支付交易和旅行行程之间存在一对一的关系。这可以显着简化协调和管理旅行费用的过程，特别是对于公司旅行。

本发明所属区段的技术人员将理解，在不脱离本发明的精神和范围的情况下，可以进行许多修改。

应当理解，如果本文提及任何现有技术出版物，则，在澳大利亚或任何其他国家，此类参考并不构成承认该出版物本领域公知常识的一部分。

在随后的权利要求和在本发明的前述描述中，除非上下文由于明确的语言或必要的含义而另外要求，单词“包括”或诸如“包含”或“包含”的变体以包含的含义使用，即，指定所述特征的存在但不排除在本发明的各种实施例中存在或添加其他特征。

首字母缩略词词汇表：

api，applicationprogramminginterface-应用程序编程接口，用于计算机系统交换数据的协议。

cvv，cardverificationvalue-信用卡验证码，信用卡的安全代码。

e.123-电子邮件地址格式的国际标准。

e.164-电话号码格式的国际标准。

fop，formofpaymentinformation-付款信息的形式，用于处理付款的付款方式(例如信用卡详细信息)。

gds，globaldistributionsystem-全球分销系统，用于搜索，预订和购买旅游产品(例如航班，酒店，汽车)的数据库和接口。

html，hypertextmarkuplanguage-超文本标记语言，用于格式化文本的计算机代码。

http，hypertexttransferprotocol-超文本传输协议，用于请求，接收和传输数据的计算机系统的协议。

isdn，integratedservicesdigitalnetwork-综合业务数字网，数字语音和数据电话网络。

ivr，interactivevoiceresponse-交互式语音响应，通过按下电话上的键或使用语音识别技术，通过电话系统与计算机系统交互的方法。

json-javascriptobjectnotation，与其他计算机系统或组件交换数据时格式化的标准。

oauth-用于在计算机系统或组件之间验证和交换授权数据的标准。

obt，onlinebookingtool-在线预订工具，旅行者直接通过其tmc计算机系统预订航班，酒店，汽车的网站。

pnr，passengernamerecord-乘客姓名记录，预订数据包含有关旅行者及其旅行的信息。

pstn，publicswitchedtelephonenetwork-公共交换电话网，模拟语音和数据电话网络。

restapi-representationalstatetransferapplicationprogramminginterface，用于通过http交换数据的计算机系统的协议。

smtp，simplemailtransferprotocol-简单邮件传输协议，用于计算机系统发送和接收电子邮件的协议。

ssl/tls，securesocketslayer/transportlayersecurity-安全套接层/传输层安全性，用于计算机系统以加密形式发送和接收数据的协议。

tde，transparentdataencryption-透明数据加密，用于加密数据库文件的microsoftsql数据库的功能。

tmc，travelmanagementcompany-旅游管理公司，专门从事企业/商务旅行的旅行社。

vcc(或vcn)，irtualcreditcard(orvirtualcardnumber)-虚拟信用卡(或虚拟卡号码)，具有固定到期日和固定支出限额的一次性信用卡号。

xml，extensiblemarkuplanguage-可扩展标记语言，用于在与其他计算机系统或组件交换数据时格式化数据的标准。