[发明专利]自底向上优化的搜索系统和方法

说明书

背景技术

现有酒店和旅行的计算机化预定系统使用自顶向下的搜索方法，从而在从搜索请求中找出（discover）单一的可用性单元(cell)时创建这些可用性单元。例如，这些系统可允许用户输入诸如酒店的标识、登记日期和结账日期之类的搜索准则来找出所选数量的夜晚（即，单次入住时长）的可用酒店房间。仅当找到产品项目（即，酒店房间）之后，方应用商业逻辑以寻找对于该特定一组产品项目的和费率和可用性。

现有技术的该方法具有若干缺点。由于该方法的自顶向下的性质，需要用逐一的搜索请求来搜索并找出产品项目（例如，可销售房间）。此外，搜索请求必须具有酒店名称/代码、登记日期和结账日期作为最低限。如果这些最少元素不在可用性请求中，则将拒绝该请求。

此外，现有技术的方法的核心服务只允许一次核对一家酒店，并且假设在搜索中使用登记和结账日期，费率和可用性响应只反映特定数量的夜晚。基本搜索不允许使用替换的日期，并且由此无法找出替换的费率。

如果进行城市搜索（即，搜索集中在一个城市），则该请求分成对单家酒店的多个搜索，并且每一个这种核心酒店搜索一次执行一个。核心搜索服务无法识别多家酒店之间的关系。由于每一核心请求一次针对一家酒店执行（其中每一请求需要执行复杂的商业规则以找到费率和可用性），因此CPU时间和资源的成本较高。另外，假设每一请求具有CPU和资源密集性质，响应时间可能相对较慢。针对每一请求找出和计算费率和可用性规则的要求花费时间。

同样，在现有技术的系统中，该请求是非常用户专用的，并且不允许交易系统帮助找出替换类型的产品，诸如不同的房间类型等。

现有技术的最大缺点可能是单一的可用性单元。

单一的可用性单元从搜索请求中的定义好的入住时长（LOS）导出。LOS从搜索请求中的起始日期和结束日期导出。看不到可从搜索请求中的LOS导出的多个可能的组合。例如，如果请求者还想要评估关于LOS的不同选项，则对于每一LOS选项，它将需要若干单独的搜索请求。现有技术没有提供替换日期或产品项目的灵活性。建立具有全部灵活性的回复所需的成本和时间此时无法节约成本。例如，如果消费者想要核对针对五月第一周的可用性，则将需要49次单独的可用性调用。针对这一周的每一天，七个可用性调用（即，7天X每一天7个LOS值）。该交易将使成本增加48次的因数（即，1次调用和49次调用之间的差值），并且将导致对消费者的很长的响应时间（即，差的用户体验）。

因此，在现有技术中存在改进旅行和酒店交易系统的需要，如下文中更详细描述的。

附图说明

结合在本说明书中且构成其一部分的附图示出了各个实施例，并且与描述一起用来解释方法和系统的原理：

图1A示出酒店预定系统的结构。

图1B示出一个实施例中的本发明的基础建筑块的结构。

图2示出另一实施例中的本发明的结构。

图3示出一个实施例中的描述本发明的高级序列图。

图4是一个实施例中的与本发明一起使用的框架结构流程图。

图5是一个实施例中的可与本发明一起使用各个计算器的示图。

图6是可用于掩码（mask）计算器的样本UML。

图7示出一个实施例中的可由本发明采用的步骤。

具体实施方式

在公开和描述本方法和系统之后，应当理解本文中所使用的术语只是出于描述特定实施例的目的而不旨在是限制性的。

如在说明书以及所附权利要求书中使用的，单数形式的“一”、“一个”以及“该”包括复数引用，除非上下文另外明确地指出。在本文中，范围可表达为从“约”一个特定值和/或到“约”另一特定值。当表达这种范围时，一个实施例只可以包括例如从一个特定值和/或到另一特定值。

类似地，当值被表达为近似值时，应当理解，通过使用修饰语“约”，特定值构成另一实施例。还应理解，每一范围的端值无论是与另一个端值联系起来还是独立于另一个端值都是有意义的。

“任选的”或“任选地”表示随后描述的事件或情形可能或可能不发生，并且该描述包括所述事件或情形发生的实例以及它不发生的实例。

在本说明书的具体实施方式和权利要求中，单词“包括”以及诸如“包含”和“具有”之类的该单词变体表示“包括但不限于”，而不旨在排除例如其他添加、组分、整体、或步骤。“示例性”表示优选或理想实施例的示例，而不旨在传递该实施例的指示。“诸如”不用于限制性的意义，而是出于解释的目的。