用于具有提高的搜索效率的售前预订系统的方法和系统的制作方法

用于具有提高的搜索效率的售前预订系统的方法和系统的制作方法
【专利摘要】根据本发明的优选实施例的所述方法提供了售前预订工具，它允许存储来自许多供应商的航空旅行的整个目录，同时以有限的运行成本确保高速缓存的高准确率。所述系统利用费用知识在可能时，即费用是公开的并且不让特定的客户议价时，合并来自不同旅行供应商（航空公司、旅行社）的一致的旅行推荐。这就防止了在所述系统中存储冗余的价格并且改进了其成本效益。根据本发明的优选实施例的所述系统依赖于几个专用的数据分析引擎以最优化数据预计算的成本同时保持良好的数据准确率。
【专利说明】用于具有提高的搜索效率的售前预订系统的方法和系统
【技术领域】
[0001]本发明涉及预订系统的领域。尤其是涉及旅行搜索中提高效率的大规模搜索平台的方法和系统。
【背景技术】
[0002]现有技术的预订系统一般基于专用的全球分销系统(⑶S)，例如航空公司预订系统，它为售票业务如航班订票提供航班搜索应用。这种行为也称为“订票销售”，涉及大量计算并可能花费某些时间。为了使这种延迟最小化，用户通常具有的自由度不多:他们必须指定出发和目的地城市、旅程的出行和返程日期。为了进一步使此延迟最小化，如果他们具有精确的航班要求，他们可以指定如优选的运行承运人和客舱等级。在最终订票的目标中，用户对具体旅程(城市配对、出发和到达日期)搜索最佳价格。此搜索通常提供某些灵活性:如对请求的旅程返回100个最便宜的航班推荐；对紧密相关的日期返回更便宜的航班。一切所需的计算(搜索最便宜票价和规则结合，检查候选航班的空余座位…)都在查询之时执行，这就确保了返回的推荐将可用于订票。因此，这样的搜索事务成本高并且完成要花几秒钟。这种成本把它们排除在答复更开放的搜索请求之外，比如未来两三个月中最便宜的航班。虽然这对于系统性能和对于响应时间有利，但是对于肯定欣赏在参数选择中自由度更宽的更加用户友好互动的用户却不理想。
[0003]对搜索航空旅行价格任务的不同方案是所谓的“售前”。以这个术语我们指要求通过预订系统询问数据库但是不一定引起真正订票的那些行为。这些行为对于航空公司和旅行社至关重要，因为即使它们不立即产生收入，它们也能够影响其潜在客户的未来选择。能够以许多自由度对用户的查询提供零延迟响应的工具会很受欢迎。利用售前，用户能够浏览承运人或旅行社的航空旅行的整个目录。这些用户希望在购买前先通过浏览超过亿万旅行推荐而作出他们的决定。与购买相比，浏览推荐隐含着对搜索的瞬时响应(几十毫秒)。因此售前系统的典型方式为让用`户浏览预计算的旅行推荐的高速缓存。利用这样的方案，搜索查询能够强有力得多:用户能够搜索许多开放的条件:仅仅出发城市、日期范围、价格范围…。例如:“搜索今后12个月内低于600欧元的从巴黎到任何目的地的两或三周的旅行”。这种方案的缺点在于，向用户返回的推荐仅仅保证在其预计算之时有效。尤其是在搜索之时它们可能不再适于订票。
[0004]不像其他高速缓存浏览域(如Wffff搜索)，航空旅行售前对航空旅行价格变动性非常敏感:最近几周中航班的最优价格很可能每天都改变。这种变动性极大地冲击了高速缓存的准确率，即售前价格与售票价格之间的一致性。业内通常的准确率大约20-30%。
[0005]维持更高的高速缓存准确率意味着大量的再计算(以应对旅行的整个目录)以及同时频繁的再计算(以应对航班变动性)。这对硬件资源要求非常高。
[0006]现有技术的售前工具具有某些缺点，它们限制了工具的效率。例如TravelTainment 售前平台:(“TTibe: TravelTainment Internet Booking EngineTittp://www.traveltainment.fr/a-propos-de-traveltainment/qu1-sommes-nous/)对其自己的预计算的旅行数据库(主要从德国城市出发的航班)提供了浏览工具。航空旅行数据如由Amadeus’Extreme Pricer 提供，它是 Massive Computation Platform (MCP)的产品。旅行数据表示了来自几千个城市配对的最便宜航班，对于今后一年的每一天，I天与23天之间的一切逗留持续时间。每一天，整个旅行数据库(几千万个价格)由Amadeus再次计算并发送到TravelTainment用于综合到其平台中。虽然从其客户的立场看旅行域是相当面面俱到的，但是这种方案有两个主要缺点:
[0007]-每天全部数据都由Amadeus再次计算，它具有运行成本
[0008]-综合这么大量的数据对于TravelTainment成本高昂并且一天只能进行一次。这对由其客户体验的价格准确率有冲击。
[0009]其他已面市的平台是Kayak的Explore
[0010](http://www.kayak, com/news/kayak-adds-map-based-search-tool-to-popular-1pad-app.bd.html),
[0011]Opodo 的 EscapeMap:
[0012](http://promos, opod0.c0.uk/airtools/escape_map.html)，
[0013]汉莎的Trip Finder:
[0014](http://www.1ufthansa.com/online/portal/lh/us/nonav/local?nodeid=3322431&l=en),它是由Amadeus技术支持的。这三个售前平台在供应其预计算解的高速缓存方面具有与TravelTainment不同的策略:它们全都依赖于记录真实的售票流量，即记录在其售票平台上操作的搜索事务的结果。这种方案具有的优点在于，预计算几乎没有成本。不过对于其各自的客户具有一系列不利结果:
[0015]-由于记录的流量，罕见的目的地可能对售前不可用；
[0016]-由于记录的流量中缺失日期，在价格域中有大量的“空洞”；
[0017]-难以建议复杂的旅行推荐，例如提前购买；
[0018]-某些易变价格推荐数日(甚至数周)未更新。
[0019]所有这些缺点都可能在很大程度上降低客户体验到的售前准确率。

【发明内容】

[0020]本发明的目标是缓解与现有技术系统相关联的至少某些问题。
[0021]根据本发明的一方面，提供了一种分布式预订系统中的方法，用于根据无约束力的旅行查询产生有报价的旅行推荐，分布式预订系统具有根据多个参数对包含旅行可行性和费用信息的多个旅行数据库的访问权限，每个旅行查询包括一组偏爱，每项偏爱与在所述多个参数当中选择的一个参数相关，该方法包括:在多个快速存取存储器位置保持包括预计算的旅行推荐的选择的高速缓存，每个旅行推荐包括对于特定旅行的按照所述多个参数中的至少一个而分类的关于费用和/或可行性的信息；向高速缓存的旅行推荐中的每一个分配指明所需的刷新频率的分数；通过在多个数据库中发起大规模查询以刷新包含在至少一些所述旅行推荐中的信息，来更新预计算的旅行推荐的选择，其中每个旅行推荐的刷新的频率取决于所分配的分数；响应于由所述系统接收的旅行查询，搜索所述多个快速存取存储器位置以发现满足包含在所述旅行查询中的所述偏爱的那些旅行推荐；向所述旅行查询的用户发出响应以及更新旅行推荐的所述选择的所述分数。[0022]根据本发明的第二方面，提供了一种系统，包括适于执行以上介绍的方法的一个或多个组件。
[0023]根据本发明的进一步实施例，提供了一种计算机程序，包括用于当在计算机上执行所述计算机程序时执行所述方法的指令。
[0024]根据本发明的优选实施例的所述方法允许存储来自许多供应商的航空旅行的整个目录，同时以有限的运行成本确保高速缓存的高准确率。所述系统利用费用知识在可能时(即费用是公开的并且不让特定的客户议价时)合并来自不同旅行供应商的一致的旅行推荐。这就防止了在所述系统中存储冗余的价格并且改进了其成本效益。根据本发明的优选实施例的所述系统依赖于几个专用的数据分析引擎以最优化数据预计算的成本同时保持良好的数据准确率。 [0025]附图简要说明
[0026]例如，现在将对附图进行参考，其中:
[0027]图1是根据本发明的一个实施例的售前预订系统的大规模搜索平台的图；
[0028]图2显示了实施本发明的大规模搜索平台的可能的预订系统；
[0029]图3-8显示了根据本发明的一个实施例的售前预订系统的大规模搜索平台的单模块组件的细节；
[0030]图9是适于支持本发明的优选实施例的方法的一般计算机系统的图；
[0031]图10是根据本发明的一个实施例的过程的方法步骤的流程图。
【具体实施方式】
[0032]根据本发明的优选实施例的分布式搜索平台旨在存储预计算的航空旅行价格并且提供了几个优点。
[0033]它被设计为保持航空旅行的整个目录。搜索平台能够对来年中一切日子存储如数千个行情的最佳价格，取决于旅行的逗留持续时间的每天的几个可能价格。本发明的分布式性质让它缩放以适应要存储的无论什么数目的行情。
[0034]它使航空旅行数据的存储最优化，具有以下益处:
[0035]-旅行搜索效率:搜索事务的可实现响应时间是几十毫秒，无论其复杂性如何(开放目的地、全年搜索…)
[0036]-旅行数据更新效率:更新对整体存储的冲击有限，利用新数据的瞬时可用性实现连续更新
[0037]-旅行数据存储效率:如果数据在许多目录中是公共的，就能够被因子分解以进一步降低存储成本
[0038]它能够以可承受的成本维持高质量的售前旅行推荐。本系统具有多种引擎检测需要再次计算的旅行价格。这能够驱动部分再次计算以节省硬件资源。节省的资源能够再次投入到其他再次计算中以实现从用户的立场看到的高速缓存的更高准确率(在80-90%的范围内)。
[0039]本系统提供了不同类型的搜索产品，取决于其客户和旅行提供商的需要。例如，承运人将可能需要某搜索产品以检索对其航空公司及其合伙人的航空公司的推荐。相反，在线旅行社将可能需要某搜索产品没有承运人过滤地检索任何类型的航空旅行。这两种产品可以具有内在的特异性并可以相应地优化。
[0040]图1显示了根据本发明优选实施例的分布式系统101，用于存储和搜索航空旅行推荐。存储的目录或航空旅行推荐遍布组成分布式系统的所有机器。在每台机器上，全局数据的子部分被存储在快速存取存储器位置(如RAM)以进行快速数据访问。图1呈现了实施本发明的系统构架的逻辑图。尽管在物理上是分布式的，但是本系统的逻辑图能够被分解为两个主要的组:
[0041]数据库103以及矩形框105和107表示分布式搜索系统的典型部件。
[0042]数据库103表示全部航空旅行推荐，逻辑上分组在若干推荐池中而在物理上跨越不同机器存储。
[0043]矩形框105和107表示供应和搜索引擎:
[0044]-供应引擎105对预计算的航空旅行推荐组(如具有相同城市配对的全部旅行)编制索引并把它们存储在分布式系统的机器之一中。
[0045]-搜索引擎107在物理机器当中对数据组定位并提供索引搜索工具以回答源自用户的查询。
[0046]椭圆项109至115表示一系列面向业务的分析引擎。它们的目的是使平台的硬件成本(从而旅行提供商的成本)最优化:它们旨在实现每天再次计算的推荐的数目与本系统中存储的预计算的价格的准确率之间好的折衷。这些引擎分析供应和搜索操作并产生对本系统中存储的数据的变动性和质量的度量。这些引擎的某些利用了⑶S (不是本发明的一部分)的其他销售服务。尤其是:
[0047]-学习引擎109每天都分析平台中存储的旅行推荐以提取有关跨越日期和行情的某些价格变动性的某些信息，即该价格保持不变多久；
`[0048]-畅销引擎111跟踪(按日期、行情…)请求最多的或返回最多的旅行推荐以得到涉及本系统中存储的最相关数据的度量。
[0049]-准确率引擎113试图检测本系统中存储的高速缓存的旅行推荐与真实销售价格即不再可预订的或价格已经改变的航班之间的差异。
[0050]-报告协调器115汇总和存储先前引擎的结果。其角色是确定在给定可用资源情况下以及根据先前引擎的结果，整个航班数据的哪个部分必须再次计算。这样的确定根据某算法进行。
[0051 ] 在本系统中，所有分析引擎都与供应和搜索引擎(105和107)并行工作，因此其工作对用户不具有性能冲击(没有响应时间恶化)。
[0052]参考图2，表示了完整的搜索平台。这样的平台包括根据本发明优选实施例的系统201作为由旅行推荐计算系统203供应的组件之一，比如在欧洲专利申请EPl 1305518.0中介绍的系统(在以下说明中我们将称这个系统为大规模计算平台，或MCP)。两个系统都可以与⑶S205提供的其他内部服务互动。
[0053]图2描述了为了在搜索平台中存储旅行推荐的整个目录要遵循的高级别流程。
[0054]作为本平台的客户，旅行提供商(航空公司、旅行社…)决定它们希望使其旅行域的哪个部分综合到搜索平台。从这点出发，它们向旅行推荐计算系统发送所谓的大规模查询，它是对旅行推荐计算系统的一系列计算命令。这些命令详细地给出了要考虑的行情(如对于来年所有日期的城市配对的列表)以及要产生的旅行推荐(如对于每天的，I与20天之间旅程长度的最佳推荐)。这样的命令可能由客户频繁地再次评估，它们也能够用作递归计
算的基础。
[0055]旅行推荐计算系统利用GDS的内部服务来计算所请求的推荐。其中为了产生推荐，它可以使用旅程服务来检索现有航班的列表；使用报价服务来找到费用与航班的最佳结合；使用可行性服务为订票商议可用的当前座位…。
[0056]产生推荐时，计算系统向根据本发明优选实施例的系统发送结果进行综合。收到的推荐被存储在专用的存储器位置以充实预计算的旅行推荐的全局高速缓存，变得对最终用户的搜索查询可用。一旦旅行推荐被综合，某些监视任务就在后台发生以检测由于与等价的销售推荐的一致性低而必须再次计算的高速缓存中的旅行推荐。这种监视可用使用GDS提供的内部服务。
[0057]检测到不一致的推荐时，根据本发明优选实施例的系统便产生一系列的计算命令(大规模查询)并将其发送到计算系统。后者将产生最近推荐，将有助于维护良好的高速缓
存一致性。
[0058]图3表现了供应引擎105(见图1)的结构和功能。供应引擎接收由旅行推荐计算系统如MCP返回的航空旅行推荐组。例如，从巴黎到伦敦(行情PAR-L0N)的一切价格。对这些数据的综合在几个步骤中发生:
[0059]-分派旅行推荐
[0060]在根据本发明优选实施例的系统中，相关数据旨在被存储在同一物理机器上以便提供非常迅速的搜索响应时间。例如，具有同一出发城市的两个行情(PAR-LON和PAR-NYC)将落在同一物理机器上。
`[0061]供应引擎从推荐组中提取信息(旅行提供商ID、办事处ID、行情、地理位置…)以确定将保留该数据的物理机器。这种数据平衡机制利用了熟知的分布式技术比如循环复用法，或者一致性散列法。正如在熟知的数据复制模式中所见，许多机器可以保留相同组的推荐以改进可靠性、容错性或可存取性。
[0062]-组织旅行推荐
[0063]供应引擎接收来自旅行推荐计算系统如MCP的旅行推荐批次。输入的数据然后被分组为所谓数据集，方式为更好地适应根据本发明优选实施例的系统。由当前介绍的系统提供的每个搜索产品都具有独特的数据组织策略以使其性能最优化。例如，为了特定需要，一组来自旅行推荐计算系统如MCP的航班可以被组织在相同城市配对的组然后分配到两种类型的数据集:1)相同城市配对且仅仅直飞；以及2)相同城市配对并带有转机的航班。
[0064]-建立加速器
[0065]在该组织的顶部，根据本发明优选实施例的系统创建了附加数据集，仅仅包含有关旅行推荐的元信息。这些数据有助于实现非常快速的搜索。例如，元信息的数据集可以保留从某出发城市可到达的城市，以及对于每个可到达城市，城市配对的最便宜价格。最终，搜索可能从这种信息获益以避免在查找了太多的旅行推荐后才返回解决方案。
[0066]-建立索引
[0067]如同数据库，根据本发明优选实施例的系统在数据集的顶部构建索引以提供快速访问时间。对于预计算的航空旅行推荐，搜索准则非常开放:人们能够搜索在给定日期范围内的价格，搜索给定的价格范围，搜索任意目的地城市…。不是每个搜索准则创建一个索弓丨，根据本发明优选实施例的系统使用熟知的多维数据结构(K-D-B树)构建每个数据集的单一索引，同时无论搜索准则如何都保持对数据的同等高效访问。这种方案限制了使用的
存储量。
[0068]如果两个旅行提供商共享公共的旅行推荐并且费用是公开的(与只适用于特定办事处ID的旅行提供商的议价相反)，这些能够在系统存储器中共享以增加空间并降低硬件成本。
[0069]-一致性管理器
[0070]从旅行推荐计算系统如MCP中能够获得新的旅行推荐时，以新的或更少的旅行推荐更新等效数据集，并且重新建立其索引。可以并发地搜索受影响的数据集用于旅行推荐。
[0071]为了防止影响正在进行的搜索(既按照性能又按照一致性)，供应引擎管理数据集的修改。在对数据集版本n进行搜索的同时，某供应构建版本n+1。对修改的数据集进行构建和编制索引后，它变成了用于搜索的新的参考数据集。不久之后，先前数据集从保留数据集的分布式系统中的所有物理机器的存储器存储中被删除。这就确保了这些数据对于正在进行的搜索被保留可用到它们完成，从而防止了一致性问题。
[0072]图4表现了搜索引擎107(见图1)。搜索引擎接收来自用户的航空旅行搜索请求，并且慢行到全部数据中以返回最好的推荐。这个过程在几个步骤中发生: [0073]-服务器密切关系
[0074]输入的搜索请求必须由根据本发明优选实施例的系统提供的特定搜索产品处理。从这点出发，它必须被传送到包含所需数据的物理机器才能回答该请求。根据针对这些推荐的搜索产品的若干特异性，航空旅行推荐由供应引擎分派到物理机器。搜索引擎执行相反的操作:它分析要回答的搜索查询并且根据其类型确定要搜索的数据以及它们所在的物理机器。
[0075]-确定搜索域
[0076]一旦搜索请求被转发到相关的物理机器，搜索引擎便确定其中要找到与搜索查询有关的元信息的数据集。元信息被用于定位包含对搜索查询的潜在解决方案的航空旅行推荐的一切数据集。
[0077]-搜索执行
[0078]一旦定位了一切潜在的航空旅行推荐，搜索引擎便根据搜索查询中表达的准则，如价格范围、日期范围、航班承运人等…，解析全部的多维索引以收集最佳的旅行推荐。
[0079]搜索引擎能够利用先前的元信息决定不搜索全部潜在旅行解决方案。例如，假设搜索查询要求从特定城市NCE启程的最佳票价。假设搜索期间，发现到目的地城市PAR的旅行是100欧元。如果元信息声称到城市NYC的最低价格是500欧元，该搜索引擎将甚至不再尝试搜索从NCE到NYC的解决方案。这进一步缩短了搜索事务的响应时间。
[0080]-相关的搜索
[0081]在搜索执行步骤不返回旅行推荐的情况下，用户的查询可能限制性太强:从而对先前考虑的每个城市配对分析缺乏匹配的原因。例如，原因可能是因为在指定的日期范围内没有航班，或者有航班但是比查询中表达的限度更昂贵。
[0082]在用户查询限制性太强的情况下，搜索引擎实施了退却策略以返回与原始查询表达的约束密切相关的推荐。它放宽对多个参数的约束(更宽的日期范围、更高的价格限度…)并循环回到搜索执行步骤。或者当找到了某些推荐时、达到了配置的重试次数时或者达到了允许的最长重试时间时，该循环结束。
[0083]在退却策略不返回任何推荐的情况下，在适用时执行另一项退却策略。在请求目的地具有地理学含义(如城市、国家)的情况下，搜索引擎使用GDS (不是本发明的一部分)提供的地理服务确定接近的地理区域，它以上面讲解过的方式，放宽了原始查询的目的地约束并循环回到搜索执行步骤。
[0084]如果两项退却策略都没有检索到推荐，便返回空结果。
[0085]-旅行解决方案汇总
[0086]一旦找到了搜索查询的全部解决方案，搜索引擎便执行忽略以合并有可能已经从不同数据集返回的一致结果。例如假若搜索已经不得不寻找了包含某城市配对最便宜的直飞航班的数据组，以及包含全部航班(直飞和带有经停)的另一个数据集，就能够出现这种情况。
[0087]最后，根据搜索查询的需要对找到的旅行解决方案进行组织:按照目的地城市、按照日期、按照价格上升、按照航空公司(或者直飞或者具有转机)把解决方案分组。然后向用户返回该结果。
[0088]图5显示了学习引擎109 (见图1)。学习引擎包括学习和统计数据库。学习引擎的目的是检测其价格不频繁地变化从而它不需要为了保持准确而频繁地再次计算的航空旅行。
[0089]学习引擎把航空旅行航班的一般性质作为其逻辑分析的基础:在今后几天计划的航班的价格非常易变，即，如果一天后对同一航班(同一出发日期)再次报价，其价格很可能已经改变。相反，几个月的计划 的航班的价格不太可能改变，如果一天后或一周后对其再次报价。
[0090]学习引擎根据以上详细介绍的性质把变动性模型与每个行情相关联。它根据其每天收到的旅行推荐维护该变动性模型(并在需要时对其进行调整)。
[0091]-记录旅行推荐的价格
[0092]当收到输入的旅行推荐时，它们被复制并且一份去往学习引擎。旅行推荐按照行情分组，即用于一个城市配对的、来年若干天的旅行推荐。注意，并非年中所有日子都产生推荐，因为本系统有可能指示旅行推荐计算系统(如MCP)仅仅再次计算跨越小范围日期的易变航班。
[0093]学习引擎提取输入的旅行推荐的价格并将其记录在专用的学习数据库中，连同其计算的日期。这些价格用作将来航空旅行数据综合的价格对比基础。
[0094]-加载行情数据和调整变动性模型
[0095]学习引擎为输入的行情加载其专用数据库中先前存储的全部价格。它将保存的价格与可获得的输入价格进行对比。
[0096]学习引擎为取决于价格对比结果的行情调整变动性模型:
[0097]当两个一致的航班具有不同的价格时，该差异被存储为学习数据库中的统计。当差异发生得太频繁时，便更新变动性模型:跨度日期范围被标注为更易变。存储有关变化频率的统计有助于缓解由于按期事件像节日假期的价格变化的影响，
[0098]如果两个一致的航班具有相同价格的期间长于基于该模型的预期，也更新该模型:跨度日期范围被标注为不太易变。
[0099]-产生变动性报告
[0100]一旦完成了对全部输入旅行推荐的分析，学习引擎便产生报告，它包含对刚刚已经被综合到本文介绍的分布式搜索平台中的数据的修改后的变动性。变动性报告对每个客户ID (数据提供者)都产生并且对每个行情、每个出发日期进行组织。
[0101]产生的报告被发送到称为报告协调器的另一个引擎。后者将最终使用这个信息源决定必须根据旅行推荐计算系统(如MCP)上的可用计算资源被再次计算的航空旅行推荐的子组。
[0102]图6显示了畅销引擎111(见图1)。畅销引擎包括畅销数据库。一输入搜索请求，畅销引擎获得从用户事务提取出搜索趋势的机会。这就给出了有关系统中存储的旅行价格畅销的洞察。
[0103]此分析在以下步骤中进行:
[0104]-输入和输出分析
[0105]输入的搜索 查询在到达搜索引擎之前被复制并且一份去往畅销引擎。对称性地，搜索事务的输出在被发送回用户之前被复制并且一份去往畅销引擎。
[0106]畅销引擎对事务的输入和输出都分析，以得到某种畅销度量。此分析产生了不同信息，取决于输入的搜索查询的准则。例如:
[0107]如果搜索查询请求特定行情(城市配对)的旅行推荐，此引擎能够从查询中提取每个行情的流行的出发日期的位次。
[0108]如果搜索查询请求来自单一出发城市的旅行推荐，此引擎能够从解决方案中提取每个出发城市和每个价格、日期范围…的优选目的地城市(目的地国家)的位次。
[0109]-在数据库中存储统计结果
[0110]从输入的查询和输出的解决方案中提取的趋势被存储在专用的畅销数据库中。这种存储按照性质是分布式的，所以(畅销引擎运行处的)任何物理机器都能够从系统的其他物理机器上产生的数据中获益。
[0111]-汇总报告和产生畅销报告
[0112]并行地，畅销引擎的递归作业是从分布式数据库中提取先前计算的统计结果并建立某种系统性畅销度量。
[0113]例如，根据为畅销分析的搜索查询的总数量，提取畅销的行情的位次，即由输入的查询最针对的行情、输出的旅行解决方案中返回的更便宜的行情…。
[0114]另一个可能性是产生有关整年中给定日期范围的最畅销行情的统计结果以提取特定事件像节日假期的趋势，或者产生有关世界上不同地理区域最畅销行情的统计结果。这种改进有助于提取更相关的畅销度量(如对国内航班…)。
[0115]然后所产生的报告被发送到报告协调器以给予其对畅销度量的访问权限。
[0116]图7显示了准确率引擎113 (见图1)。准确率引擎包括价格准确率数据库。
[0117]准确率引擎的目标是控制预计算的航空旅行推荐并检测其价格偏离真实(即当前)销售价格太多的航空旅行推荐。此引擎的原理是使用外部Amadeus销售服务(不是本发明的一部分)发出销售事务，并且把返回的价格与高速缓存的旅行推荐价格进行对比。
[0118]这个引擎在几个步骤中操作。[0119]-使用输入和输出事务，带有节流
[0120]如同畅销引擎，准确率引擎接收一份复制的输入的搜索查询和输出的旅行解决方案。
[0121]为了避免发出在硬件成本和响应时间上昂贵的太多的真实销售事务，施加了节流忽略以便在通过本文介绍的分布式搜索平台的自然流量的子组上操作。
[0122]-产生费用搜索事务
[0123]人们必须确保准确率引擎将产生费用搜索事务，它们足够多样化，以便分析在系统中存储的旅行推荐的有代表性子组。为了如此做，产生策略是双重的:
[0124]根据旅行畅销产生费用搜索事务:准确率引擎访问(更早呈现的)畅销数据库以分析输出的解决方案的畅销性并仅仅保留最畅销的解决方案用于进一步分析。这使得由用户体验的关于高速缓存的价格与真实销售价格的一致性最大化。
[0125]根据高速缓存的旅行推荐内容产生随机事务。随机选择旅行进行分析旨在提供旅行推荐的整个高速缓存的最终准确率。它确保了对用户的旅行发现能力良好，即也监视了不畅销航班的准确率，尽管为了限制硬件成本不太经常做。
[0126]-汇总数据
[0127]汇总的准确率度量被存储在专用的分布式准确率数据库中。递归作业把全部准确率度量合并到几份报告中(按客户、按行情、按出发日期…的解决方案的准确率)并且把它们发送到报告协调器以便进一步使用。
[0128]图8显示了报告协调器115 (见图1)。报告协调器是根据本发明优选实施例的系统的最后一个业务分析引擎。其角色`是是根据先前引擎报告的全部度量以及根据旅行推荐计算系统(如MCP)中可用的计算资源，决定平台中数据的哪个部分必须再次计算。
[0129]再次计算的决定在几个步骤中进行。
[0130]存储报告
[0131]来自输入的变动性、畅销和准确率报告的全部度量都本地地存储在专用的报告数据库中。这种存储是必需的，因为报告协调器根据先前的度量选择其决定。例如，报告协调器根据变动性报告推断旅行推荐的高速缓存中存储的数据的老化。这种信息然后保存在报告数据库中。
[0132]再次计算决定
[0133]为了平衡高速缓存的数据准确率与计算系统(如CMP)上的计算资源，由报告协调器作出的决定基于试探法。
[0134]基本方式为在给定了计算系统(如CMP)上可用资源的情况下，再次计算高速缓存中最不准确的旅行推荐。在最不准确的数据当中，为了产生再次计算次序，首先考虑的是最畅销的数据。
[0135]为了在航班域中形成邻近旅行的分组(对每个行情的接近日期范围)，由报告协调器选择再次计算的候选者。这就允许旅行推荐计算系统与某些再次计算结果交互作用并对其资源消耗进一步优化。
[0136]在每个再次计算次序之间，报告协调器利用(报告数据库中存储的)变动性模型和推断的旅行推荐的老化以更新在MSP中全部剩余数据的预测准确率。
[0137]参考图9，以950表示了系统的普通计算机(如计算机、预订服务器、数据库管理子系统、路由器、网络服务器)。由并联到系统总线953的几个单元形成了计算机950。详细地说，一个或多个微处理器956控制着计算机950的运行；RAM959被微处理器956直接用作为工作存储器，而ROM962存储着计算机950引导程序的基本代码。外围设备单元(利用相应接口)围绕局域总线965集聚。尤其是，大容量存储器由硬盘968和用于读取CD-ROM974的驱动器971组成。不仅如此，计算机950包括输入设备977 (例如，键盘和鼠标)以及输出设备980 (例如，监视器和打印机)。网络接口卡983用于把计算机950连接到网络。桥接单元986接口系统总线953和局域总线965。每个微处理器956和桥接单元986都能够运行为主代理，请求访问系统总线953传送信息。仲裁器989管理着与系统总线953互斥访问权限的授权。如果系统具有不同的拓扑或者它基于其他网络，类似的考虑也适用。作为替代，若干计算机具有不同的结构，包括等效单元，或者由其他数据处理实体(比如PDA、移动电话等)组成。
[0138]在图10所示的图中也表现了以上介绍的方法。本方法是售前工具(即根据非绑定旅行查询产生有报价的旅行推荐)，它运行其中的分布式预订系统具有根据多个参数对包含旅行可行性和费用信息的多个旅行数据库的访问权限，每个旅行查询都包括一组偏爱，每项偏爱都与在所述多个参数当中选择的某参数相关。此分布式订票系统包括多个快速存取存储器位置，其中保持着旅行推荐的选择，所以用户能够具有对其查询的快速响应。我们以术语“预计算的旅行推荐组成的高速缓存”指这些快速存取存储器，即使本领域技术人员将认识到，这个术语在技术上不完全适合，因为与高速缓存相反，在快速存取存储器中存储的内容表示整个旅行目录而不仅仅为包括最常访问的旅行目录的子组。换言之，术语高速缓存与“销售事务高速缓存”有关。类似地，在这些快速存取存储器上存储的信息被称为“高速缓存信息”(如“高速缓存的旅行推荐”)。预计算的旅行推荐的高速缓存的问题在于，在推荐中包含的数据需要被更新以便使其价格与在销售期间发现的真实价格保持一致。这是一种(按照时间和系统性能)非常昂贵的活动并且在信息的一致性与系统性能之间必须找到平衡。本发明的主要特征之一是不同的旅行推荐不在同一时间以及以同一频率更新；而是“频率”分数被分配到每个旅行推荐，根据其安排更新:很可能更易变的信息将被更频繁地刷新。本方法在黑色圆1001处开始然后去往框1003，其中系统在多个快速存取存储器位置上保持由预计算的旅行推荐的选择组成的高速缓存，每个旅行推荐都包括对特定旅行的费用和/或可行性的信息，按照多个参数至少其一分类。以上面讲解的几种方式能够进行高速缓存的旅行推荐的分类和索引编制:为了在可能的最短时间中识别出正确信息这是重要的。然后指明所需刷新频率的分数被分配给每个高速缓存的旅行推荐(步骤1005)。这个分数将被用于确定何时应当进行信息的刷新。根据本发明优选实施例的刷新(步骤1009)以上面讲解的批处理进行:在本发明优选实施例中，大规模查询通过专用的子系统发起，如专用的旅行推荐计算系统例如以上陈述的大规模计算平台。这样的大规模查询的发起(步骤1007)能够在固定的时间进行或者由用户调用或者由特定事件触发:例如，大规模查询可以在每个预定的时段(如在每天的结束时或每小时)进行；当收到临界量的查询时或者达到最大容量时有可能自动地执行它；或者另外由系统管理员或由旅行提供商可以请求它。当收到用户查询时(步骤1011)，本系统首先尝试快速存取存储器位置内的搜索(1013)。如果没有找到解决方案(步骤1015)那么有可能起动可选的退却动作(步骤1017);如果没有提供退却动作，给用户的消息将通知在本系统中没有可用的结果。作为替代，考虑到用户的查询可能限制性太强，可能以调整后的参数起动新的搜索:从而对先前考虑的每个城市配对都分析匹配缺乏的原因。例如，原因可能是在指定的日期范围内没有航班，或者有航班但是比查询中表达的限度更昂贵。在用户查询限制性太强的情况下，搜索引擎实施了退却策略以返回与原始查询表达的约束密切相关的推荐。它放宽对多个参数的约束(更宽的日期范围、更高的价格限度…)并循环回到搜索执行步骤。或者找到了某些推荐时、达到了配置的重试次数时或者达到了允许的最长重试时间时，该循环结束。在退却策略不返回任何推荐的情况下，在适用时执行另一项退却策略。在请求目的地具有地理学含义(如城市、国家)的情况下，搜索引擎使用⑶S (不是本发明的一部分)提供的地理服务确定接近的地理区域，它以上面讲解过的方式，放宽了原始查询的目的地约束并循环回到搜索执行步骤。如果两项退却策略都没有检索到推荐，便返回空结果。又一个可能的解决方案将会是起动对外部数据库的查询以找到请求的旅行推荐并充实预计算的旅行推荐的高速缓存。如果得到了结果将以这条新信息充实预计算的旅行推荐的高速缓存。在任何情况下都向用户发出响应(步骤1019)。旅行推荐的分数也有可能需要更新。在本文介绍的实施例中，由查找售前信息的用户发送查询，即有关如旅行可行性、费用、时间的信息或者未必旨在完成预订的一般信息。在本发明的优选实施例中，接收查询并进行数据库询问以满足用户查询的系统与实际的预订系统是分开的，但是本领域技术人员将认识到，这两个系统(售前和预订)有可能集成在一起。
[0139]应当认识到，可以对以上内容进行改变和修改而不脱离本公开的范围。自然，为了满足局部和特定的需求。本领域技术人员可以对以上介绍的解决方案应用许多修改和改变。确切地说，尽管参考本公开的优选实施例已经以一定程度的具体性介绍了本公开，但是应当理解，形式和细节的多种省略、替换和改变以及其他实施例是可能的；不仅如此，明显的意图在于，作为设计选择的一般事项，连同本公开的任何公开的实施例所介绍的特定要素和/或方法步骤都可以合并在任何其他实施例中。
[0140]如果以不同的方式构造程序(它可以用于实施本公开的每个实施例)或者如果提供了附加的模块或功能，类似的考虑也适用；同样，存储器结构可以为其他类型，也可以用等效的实体替代(未必由物·理存储器介质组成)。不仅如此，提议的解决方案有助于用等效的方法(具有类似的或附加的步骤，即使以不同的次序)实施。在任何情况下，本程序都可以采取适于由或连同任何数据处理系统使用的任何形式，比如外部或驻留软件、固件或微代码(或者以目标代码或以源代码)。不仅如此，本程序可以在任何计算机可用的介质上提供；该介质可以是适于包含、存储、交流、传播或传送本程序的任何元件。这样介质的实例是固定磁盘(其中本程序能够被预加载)、可移动磁盘、磁带、卡、线路、光纤、无线连接、网络、广播电波等；例如该介质可以是电子的、磁性的、光学的、电磁的、红外线的或半导体类型。
[0141]在任何情况下，根据本公开的解决方案都有助于用硬件结构(例如，集成在半导体材料的芯片中)或者用软件和硬件的结合执行。
【权利要求】
1.一种分布式预订系统中的方法，用于根据无约束力的旅行查询产生有报价的旅行推荐，所述分布式预订系统具有根据多个参数对包含旅行可行性和费用信息的多个旅行数据库的访问权限，每个旅行查询包括一组偏爱，每项偏爱与在所述多个参数当中选择的一个参数相关，所述方法包括: -在多个快速存取存储器位置保持包括预计算的旅行推荐的选择的高速缓存，每个旅行推荐包括对于特定旅行的按照所述多个参数中的至少一个而分类的关于费用和/或可行性的信息； -向高速缓存的旅行推荐中的每一个分配指明所需的刷新频率的分数； -通过在多个数据库中发起大规模查询，以刷新包含在至少一些所述旅行推荐中的信息，来更新预计算的旅行推荐的选择，其中每个旅行推荐的刷新的频率取决于所分配的分数； -响应于由所述系统接收的旅行查询，搜索所述多个快速存取存储器位置以发现满足包含在所述旅行查询中的所述偏爱的那些旅行推荐； -向所述旅行查询的用户发出响应以及更新旅行推荐的所述选择的所述分数。
2.根据权利要求1的方法，其中，指明所需的刷新频率的所述分数包括指明关于旅行推荐的可行性和/或费用的信息的变动性的数值。
3.根据上述任一项权利要求的方法，其中，指明所需的刷新频率的所述分数包括指明旅行推荐的畅销的数值。
4.根据上述任一项权利要求的方法，其中，对多个旅行数据库的访问以及丰富预计算的旅行推荐的选择的步骤借助于专用的子系统来执行。·
5.根据上述任一项权利要求的方法，进一步包括: -将预计算的旅行推荐的所述选择划分为多个同类组，其中，一个同类组中的每个旅行推荐具有带有相同值的至少预定数目的参数，以及将每个组存储在所述快速存取存储器位置之一中。
6.根据上述任一项权利要求的方法，其中，所述发起大规模查询的步骤以预定的时间间隔执行。
7.根据上述任一项权利要求的方法，其中，以批处理执行所述大规模查询。
8.根据上述任一项权利要求的方法，其中，根据多维数据结构对所述多个快速存取存储器位置上存储的旅行推荐编制索引。
9.根据上述任一项权利要求的方法，进一步包括: -响应于通过搜索所述多个快速存取存储器位置没有获得结果，对所述多个参数以放宽的约束发起一系列密切相关的查询，旨在为了信息目的返回接近的结果。
10.根据权利要求1至8中任一项的方法，进一步包括: -响应于通过搜索所述多个快速存取存储器位置没有获得结果，向用户发出报警消息。
11.一种计算机程序，包括用于当在计算机上执行所述计算机程序时执行根据上述任一项权利要求的所述方法的步骤的指令。
12.—种计算机程序产品，包括包含权利要求11的计算机程序的计算机可读装置。
13.一种用于售前系统的软件工具，包括根据权利要求1至10中任一项的所述方法。
14.一种分布式数据处理系统，用于管理售前旅行查询，所述分布式数据处理系统具有根据多个参数对包含关于旅行可行性和费用信息的多个旅行数据库的访问权限，每个旅行查询包括一组偏爱，每个偏爱与在所述多个参数中选择的一个参数相关，其中，所述系统包括适于执行根据权利要求1至10中任一项所述的方法的一个或多个组件。
15.一种被配置在数据处理系统中的业务，用于实施根据权利要求1至10中任一项所述的方 法。
【文档编号】G06F17/30GK103597503SQ201280028452
【公开日】2014年2月19日 申请日期:2012年4月27日 优先权日:2011年6月27日
【发明者】D·夏布里尼, C·雷诺, L·伊斯纳尔迪, G·莱纳德, R·戈莱 申请人:阿玛得斯两合公司