用于管理对一个或多个目录项目 的预订请求的系统和方法 【技术领域】
总体来说，本发明涉及一种在线旅游信息和预订系统，更具体来说，涉及用来管理目录项目查询和对于各种目录项目的预订请求的系统和方法。
背景技术
在旅游行业中，传统的旅游服务和代理具有悠久的历史。概括来说，传统的旅游服务向消费者提供途径以了解同旅游相关的提供商，以使消费者能够预订或者购买各种商品(goods)或服务。例如，传统的旅游服务商(travel service)能够在消费者和一定数量的旅游相关产业(例如航空公司、旅馆、导游公司、航船公司等)之间建立联系。然而，使用传统的旅游服务，消费者需要拜访该旅游服务商的物理地址，来完成希望的任务。消费者经常进行多次往返，通常每次都必须在这些旅游服务商的办公时间完成。因此，一些传统的旅游服务设施(implementation)的用户可以拜访的店铺的地理位置的数目以及营业时间都有限，在这个意义上传统的旅游服务设施是有缺陷的。此外，尽管一些传统的旅游服务商提供电话服务，消费者仍然可能经历由不同旅游服务员工引起的服务质量的不同，和/或由有限的旅游服务时间引起地服务可获得性的不同。
计算设备的发展，例如个人计算机、移动电话、个人数字助理以及一些相应的基于计算机的业务，已经试图减少对于传统的旅游服务的需要。在一个特别普遍的实现方式中，一些旅游服务商使用计算设备来和用户通信。更具体来说，旅游服务商可以使用因特网，通常称为“网络(Web)”或者“万维网(World Wide Web)”的大量的计算机来建立通信。这样的旅游服务商通常被称为基于网络的旅游服务商。
如同应用于基于网络的旅游服务商，许多网络上的旅游服务商通过向消费者提供一个或多个交互的显示(通常称为网站)来与潜在的旅游者之间进行交互，以便通过允许用户进行购买、修改、查询等来办理业务。通过与网站交互，例如通过以键盘输入数据，或者通过选择图形显示标准，用户能够控制计算机和网站，来完成各种旅游相关的任务。此外，用户可以在一天中的不同时间来完成这些任务，而且并不需要亲身到一个特定的物理旅游服务地点。
基于网络的旅游服务商和旅游产品提供商之间的关系可以特征化地描述为代理形式，或者贸易商形式(merchant configuration)。在代理形式中，基于网络的旅游服务商作为消费者计算设备和各种提供商之间的媒介，但是旅游服务对于被销售的目录项目(例如旅馆房间、航空机票、打包的航行服务(cruise package)等)并不具有完全的销售权利。相反，在管理对于用户的目录项目价格方面，每个目录项目都部分地处于提供商的控制之下。例如，在代理形式下，如果潜在的旅游者需要一张机票，代理形式的旅游服务商有可能能够完成消费者的预订，但是该代理有可能不限于设定消费者支付的机票价格。此外，代理形式的旅游服务商对于如何从用户收取费用具有有限的控制权力。这样，关于代理形式中的收入，基于网络的旅游服务商通常只限于从提供商收到的交易金额中获取一定比例。或者，基于网络的旅游服务商也可以对于每笔处理的交易收取固定的服务费用。此外，基于网络的旅游服务商可以收取固定的费用来为特定提供商的目录项目做广告。
代理形式可能在几个方面是有缺陷的。一方面，基于网络的旅游服务商被限制在仅仅向用户提供在提供商和旅游服务商之间通信的时刻可获得的目录项目。例如，传统的基于网络的旅游服务商经常为当预订请求发送到提供商处的时候可能无法获得的目录项目做广告。此外，即使目录项目可以获得，基于网络的旅游服务商对于提供给用户的产品/服务的价格也只有有限的控制。这样，基于网络的旅游服务商对于它可以在不同经济市场中，从不同的消费者交易里面获得的收入的控制减少了。因此，代理形式的旅游服务可能是提供基于网络的旅游服务的一种有缺陷的方法。
相比较来说，在贸易商形式下，各种提供商给基于网络的旅游服务商分配目录(例如旅馆房间、航空座位、航海套餐(cruise suite)等)，使得基于网络的旅游服务商对于如何处理目录具有控制能力。例如，一个旅馆提供商可以将旅馆中的一个房间售卖/委托给基于网络的旅游服务商，使得基于网络的旅游服务商具有向用户出售该旅馆房间的使用权的能力。不象代理形式中，基于网络的旅游服务商对于目录项目的价格以及如何从用户收取费用有更多的控制。更具体来说，关于收入，在贸易商形式中，基于网络的旅游服务商的收入通常取决于用户支付给基于网络的旅游服务商的价格和该项服务必须支付给提供商的价格之间的差价。这样，贸易商形式的基于网络的旅游服务商对于它的收入流有更多的控制。
在典型的贸易商形式的商业交易中，基于网络的旅游服务商获得目录项目的一部分，例如在一系列日期的特定航班上的一部分座位(例如，8月份在航班492上的10个座位)，或者在一个日期范围内的一部分旅馆房间(例如，在8月1-7号这一周内ABC旅馆的顶部套房(penthouse suit))。目录项目的各个部分的配额可以称为批量目录(batch inventory)。为了管理批量目录，基于网络的旅游服务商根据一个或多个识别特征来对目录项目进行分类。例如，根据辨识特征，例如位置(如，旅馆的名字和地址)、房间类型(如套间)以及使用日期(如2001年7月28日)，旅馆房间批量目录项目的可区分的各个部分可以被处理并存储。因此，根据不同类型的符合条件项目的数目，旅馆房间目录项目可以先根据旅馆名称，之后根据房间类型，最后根据存在日期进行分类。
尽管传统的特征分类方法有助于贸易商形式中的目录管理，缺陷有可能出现在具有相同的可识别特征，而在不可识别特征上不同的批量目录项目上面。参考上面的例子，假定旅馆分配给一个基于网络的旅游服务商一部分具有一组可识别特征的房间。与传统的分类方法相一致，基于网络的旅游服务商根据它的可识别特征(如2001年5月21日XYZ旅馆的20个双人房间)来存储目录项目。然而，如果旅馆提供商分配了具有完全相同的可识别特征，但是不可识别特征不同(如价格、限制条件、服务费)的第二个批量目录(如2001年5月21日XYZ旅馆的30个双人房间)，传统的处理方法在多种情况下都可能有缺陷。
关于潜在的用户价格/提供商价格缺陷，因为所有类似的目录项目被分在一起，传统的分类和处理方法不能有效地管理各个目录项目的不同的成本/价格(如，该20个双人房间每间为$50，该30个双人房间每间为$65)。为了解决供应商价格的不同，一些贸易商形式的旅游服务商将提供商价格/用户价格在特定目录项目的分配实例总数之间(across，在…之间？)进行平均。关于前面的例子，这会使得考虑50个房间的旅游服务的价格平均在$59。这样，由于对一些顾客收取低价，并通过对另一些顾客收取高价来弥补这个差额，基于网络的旅游服务商有损失收入的潜在可能性。本领域技术人员会理解，这种方法可能有缺陷，因为它假定旅游服务商将会售出它的目录项目的全部配额(allotment)，而这样的事情并不是总能发生。此外，由于进行不同的消费者标价交易，可能会在消费者中形成一些负面的影响。
与处理批量目录有关的另一个缺陷涉及具有使用限制的一部分批量目录项目。例如，假定提供商分配了没有使用限制的第一批房间，并随后分配了第二个批量目录的房间(具有同样的识别特征)，规定第一个批量目录的房间必须首先售出。在传统的贸易商形式的旅游服务之下，由于这些房间具有相同的识别特征，基于网络的旅游服务商将房间的数据存在一起。然而，由于传统的基于网络的旅游服务商通常不能区分目录项目中的单独的一个(individual piece of inventoryitem)对应于哪次批量目录配额，因此使用上的限制很难执行。这样，传统的旅游服务商在试图处理批量目录的过程中有各种缺陷。
与传统的贸易商形式有关的另一个缺陷，并且不必须限于批量目录，来自于基于网络的旅游服务商协调不同的提供商的努力。在一个典型的实施例中，目录项目的分配取决于旅游服务代理和提供商代理之间的使用几种通信模式(如电话、电子邮件、传真和传统邮件)的通信。经常，无法建立连续的通信会引起遍布该项交易不同部分的延迟，例如，在通知提供配额、确认接受配额以及谈判附加目录或改变条款的过程中。例如，假定一个基于网络的旅游代理试图与旅馆提供商谈判，以便以特定价格获得一部分房间的配额。谈判可能因为提供商和旅游服务商之间没有标准的通信形式(如，一个代理倾向于采用电话，而另一个使用通常的邮件)。此外，即使双方能够建立通信，并且提供商代理和旅游服务商代理之间能够达成协议，该协议也有可能没有被正确备案以备以后使用。例如，在账目核对过程中，旅游服务商的会计部门，从代理中被去除(removed from the agent)，在帐务核对过程中，可能在向提供商提供适当的授权(authorization)以便在谈判的价格上接受房间配额方面有麻烦，尤其是如果账目是在一段时间之后进行核对。这样，传统的贸易商形式的旅游代理必须建立与每个潜在的提供商进行合作(interface)的步骤，并且还必须为每种类型的提供商保存足够的记录，而这样是没有效率的。
因此，需要一套管理目录项目的系统和方法，以协助处理消费者对于目录项目的预订请求。更具体来说，需要一套系统和方法，用来管理对于具有不同特征的多个目录项目的预订请求。
【发明内容】
提供了用来管理对于一个或多个目录项目的预订请求的系统和方法。用户预订请求被获得并处理，以识别与预订请求相匹配的目录数据。根据用户预订请求生成预订交易、预订项目和预订目录纪录。如果交易能够被完成，则发给用户确认信息并发给提供商一份通知。
根据本发明，提供了处理对于一个或多个目录项目的预订请求的方法。预订处理应用程序(application)获得用户对于预订至少一个目录项目的请求。预订处理应用程序获得对应于一个或多个目录项目的目录数据，并对用户预订请求进行匹配。预订处理应用程序根据匹配的目录数据生成预订交易、一个或多个预订项目以及一个或多个预订目录纪录。预订交易纪录包括与一个或多个预订请求相关联的数据。每个预订项目纪录对应于预订交易纪录，并识别一组与特定预订请求相关联的目录项目。每个预订目录纪录对应于预订项目纪录，并包括与对于在预订项目纪录中识别出的目录项目的预订请求相关联的数据。预订处理应用程序处理预订交易、预订项目和预订目录纪录，并发送对预订交易、预订项目和预订目录纪录的处理结果。
根据本发明的另一个方面，提供了处理对于一个或多个目录项目的预订请求的系统。本系统包括至少一个客户端计算机，可操作它来生成对于至少一个目录项目的预订请求。本系统还包括用来存储对应于一个或多个目录项目的目录数据的旅游服务器。旅游服务器可操作以获得来自于客户端计算机的预订请求。旅游服务器生成并处理对应于预订请求和目录数据的预订交易、一个或多个预订项目以及一个或多个预订目录纪录。
根据本发明的另一个方面，提供了用于处理对于一个或多个目录项目的预订请求的、具有计算机可执行组件(component)的计算机可读媒质。计算机可执行组件包括一个预订交易组件，可操作以识别对目录项目的一个或多个预订请求。计算机可执行组件还包括对应于预订交易记录的一个或多个预订项目组件，可操作以用来识别对目录项目的预订请求。计算机可执行组件此外包括与预订项目组件相关联的一个或多个的预订目录组件，可用来定义对于各个目录项目的预订请求。
根据本发明的此外另一个方面，提供了用于处理来自于一个或多个目录项目的预订请求的方法。预订处理应用程序获得用户对于对应于至少一个目录项目的预订行为的请求。预订处理应用程序获取对应于目录项目的已存在的预订交易、预订项目和预订目录纪录。预订交易纪录包括与一个或多个预订请求相关联的数据。一个或多个预订项目纪录对应着该预订交易纪录，并且识别一组与特定预订请求相关联的目录项目。一个或多个预订目录纪录对应着该预订项目纪录，并且包括与对于在目录预订项目纪录中识别的目录项目的预订请求相关联的数据。预订处理应用程序根据预订行为请求(reservation actionrequest)来处理预订交易、预订项目和预订目录纪录。预订处理应用程序发送对预订交易、预订项目和预订目录纪录的处理结果。
【附图说明】
通过参考下文的详细介绍，并结合附图，本发明的前述方面和许多将随后介绍的优点将会变得更加容易评价，同样也更加容易理解。附图中，
附图1是因特网的代表性部分的框图。
附图2是显示根据本发明形成的旅游管理系统的框图。
附图3是描绘根据本发明形成的客户端计算设备的示意性结构的框图。
附图4是描绘根据本发明形成的旅游服务器的示意性结构的框图。
附图5是根据本发明形成的三个细节级别(three detail level)的目录项目数据关系的框图。
附图6是附图2的旅游管理系统的框图，显示了根据本发明进行的客户端计算设备目录查询。
附图7是显示根据本发明，由目录处理应用程序执行的目录请求处理程序的流程图。
附图8是显示根据本发明，由目录处理应用程序执行的查询可获得的目录子程序的流程图。
附图9是显示根据本发明，目录处理应用程序使用的数据关系的框图。
附图10是附图2的旅游管理系统的一个框图，显示了根据本发明进行的、旅游服务器对于来自于提供商的目录的请求。
附图11是附图2的旅游管理系统的一个框图，示例了根据本发明进行的提供商目录行为(action)请求。
附图12是附图2的旅游管理系统的一个框图，示例了根据本发明进行的提供商目录行为请求。
附图13是显示了根据本发明，由目录处理应用程序执行的提供商目录行为请求处理程序的流程图。
附图14是显示了根据本发明，由目录处理应用程序执行的提供商批量目录行为请求子程序的流程图。
附图15是显示了根据本发明，由目录处理应用程序执行的提供商目录查询行为子程序的流程图。
附图16是代表了根据本发明，被目录处理应用程序使用的目录关系(relational)数据库的数据关系的框图。
附图17是根据本发明形成的三个细节级别的预订数据关系的框图。
附图18是附图2的旅游管理系统的框图，显示了根据本发明进行的、客户端计算设备对于预订的请求。
附图19是附图2的旅游管理系统的框图，显示了根据本发明的、客户端计算设备对于来自于提供商的预订的请求，其中该提供商与旅游管理系统并非持续连接。
附图20是显示了根据本发明，由预订处理应用程序执行的预订处理程序的流程图。
附图21是显示了根据本发明，由预订处理应用程序执行的处理新用户预订请求子程序的流程图。
附图22是显示了根据本发明，被预订处理应用程序用来处理预订请求的数据关系的框图。
附图23是根据本发明，由预订处理应用程序执行的处理用户预订取消请求子程序的流程图。
附图24A和24B是由根据本发明，预订处理应用程序执行的处理用户预订修改请求子程序的流程图。
附图25是代表了根据本发明，被预订处理应用程序所使用的用于预订关系数据库的数据关系的框图。
【具体实施方式】
如上所述，本发明的各个方面在通过因特网可连接的万维网(“WWW”)或者网络(“Web”)站点中被体现出来。如本领域技术人员所熟知的，术语“因特网”(“Internet”)指使用传输控制协议/因特网协议(“TCP/IP”)相互通信的网络和路由器的集合。附图1显示了因特网20的一个代表性部分，其中多个局域网(“LAN”)24和一个广域网(“WAN”)26通过路由器22互相连接在一起。路由器22是用于作为界面将一个LAN或者WAN与另一个连接在一起的专用计算机。LAN之内的通信连接可以是双绞线、同轴电缆或者光纤，而网络之间的通信连接可以使用56Kbps模拟电话线路、1Mbps数字T-1线路、45Mbps数字T-3线路或者本领域技术人员已知的其它通信线路。
此外，计算机28和其它相关的电子设备可以通过调制解调器和临时电话或无线链路，被远程连接到LAN 24或者WAN 26。可以理解，因特网20包括大量的这种互相连接的网络、计算机和路由器，在附图1中仅显示了因特网20的具有代表性的一小部分。
由于因特网的价值在于它能够连接位于世界各地的计算机，最近，它发生了爆炸性的增长。随着因特网的增长，WWW也获得了发展。像本领域技术人员所理解的，WWW是互相连接在一起的或者用超文本链接标记语言(“HTML”)或者其他链接标示语言(makeuplanguages)写成的“超文本”(“hypertext”)文件的大集合，其中这些文件以电子方式存储在遍布因特网的“WWW站点”或者“Web站点”中。其它交互式的超文本环境可能包括一些专有的环境(如美国在线或者其它在线服务提供商所提供的环境)，以及由各种无线网络提供商(尤其是蜂窝电话产业中的那些无线网络提供商)提供的无线互联网(“wireless Web”)。可以理解，本发明可以应用在任何这样的交互式超文本环境中，然而，为了便于讨论，关于本发明，网络被用来作为示例性的交互式超文本环境。
网站是连接到因特网的、拥有海量存储能力来存储超文本文件并运行管理软件来处理对于存储的超文本文件的请求的服务器/计算机。嵌在超文本文件之中的是一些超级链接，例如，将文件链接到存储在因特网上其它地方的网站中的另一个超文本文件的文本的加亮部分。每个超级链接被分配一个统一资源定位器(“URL”)，它提供被链接文件在连接到因特网的服务器上面的确切位置，并描述该文件。这样，无论超文本文件从什么网站服务器被检索，该文件都被认为是从万维网中检索。本领域技术人员知道，网络服务器也可能包括存储和发送应用程序的设施(facility)，如以Sun Microsystems公司的JAVA程序语言写成的应用程序，用来在远端计算机上执行。类似地，网络服务器也可能包括在网站服务器自身执行脚本和其它应用程序的设施。
消费者或者其它远程登录用户可以通过网络浏览器程序从万维网检索超文本文件。网络浏览器，如Netscape的NAVIGATOR或者Microsoft的Internet Explorer，是用来为万维网提供图形用户界面的软件应用程序。根据用户通过网络浏览器发出的请求，网络浏览器使用文件的URL和HTTP协议来从合适的网络服务器定位并检索希望获得的超文本文件。HTTP是比TCP/IP更高级的协议，特地设计用来满足万维网的需求。HTTP运行在TCP/IP的上层，用来在服务器和客户端计算机之间传送超文本文件。万维网浏览器也可能从网络服务器检索程序，例如JAVA程序，用来在客户端计算机上执行。
总体来说，本发明涉及用来管理目录项目查询和预订请求的系统和方法。更具体来说，在本发明的一个实施例中，提供了用来在目录项目提供商和消费者之间管理旅游相关的目录项目查询和旅游相关的预订交易的一套系统和方法。本领域技术人员会理解，目录项目包括可以从提供商传递到消费者的任何实际的物品或者商品物件(articleof merchandise)，如门票、通行证、消费者产品。目录项目也可以包括由提供商或者提供商的代理提供的、对于物品或服务的权利，如在特定夜晚占据一间旅馆房间的权利，对于航班的一个座位的权利，占据航船上特定船舱的权利。此外，可以理解，目录项目可以是单件的物品或服务以及一组大体相同的物品或服务(如旅馆的一部分房间)。
取决于所希望的交易，贸易商形式的旅游管理系统可以被用于辅助消费者查询目录项目的可获得性，以及处理消费者对于目录项目的预订请求。此外，旅游管理系统可以被用于辅助各种基于提供商的目录项目行为请求，以及将消费者预订信息通知提供商。然而，本领域技术人员会理解，公开的实施例被用于示范的目的，不应当被理解为限制。
附图2是示例根据本发明的旅游管理系统230的框图。如附图2所示，旅游管理系统230包括一个或多个客户端计算设备232，以及具有用来存储分配给该旅游服务商的目录项目的目录存储器238的旅游服务器236。此外，旅游管理系统230包括一个或多个的具有提供商目录存储器241的提供商系统240。在本发明的一个实施例中，客户端计算设备232通过存储在客户端计算设备232的内存中的网络浏览器234，与旅游管理系统230进行通信。
如附图2所示，旅游管理系统230的各种组件通过在标准的通信网络(例如因特网20)中发送数据和接收数据来进行通信。然而，本领域技术人员会理解，客户端计算设备232、旅游服务商236和提供商240也可以通过专用或者半专用通信网络，如专用的基于旅游的计算机网络，来发送/接收数据。此外，尽管在附图2中只显示了两个客户端计算设备232，本领域技术人员会理解，在根据本发明的旅游管理系统230中，可以使用任何数目的客户端计算设备232或者提供商240。类似地，如附图2所示，旅游管理系统230可以通过其它中间提供商204A，如提供商240A、240B和240C所示，间接地与供应商系统相连接。
附图3是描绘了根据本发明的用于与旅游管理系统230进行交互的客户端计算设备232(附图2)的示范性结构的框图。具有本领域的普通知识的技术人员会理解，客户端计算设备232包括比附图3所示的多很多的组件。然而，并不是所有这些为本领域技术人员所熟知的广泛使用的传统组件都需要被显示出来以公开用来实现本发明的实施例。
如附图3所示，客户端计算设备232包括网络接口300，用来直接连接到LAN或者WAN，或者用来远程连接到LAN或者WAN。具本领域技术人员会理解，网络接口300包括用于这样的连接的必要的电路，并且其结构被制造得可以使用多种通信协议，如TCP/IP协议、因特网Inter-ORB协议(“IIOP”)以及类似协议。网络接口300可以使用它所连接到的LAN或者WAN的特定网络配置的通信协议，以及一种特定类型的耦合介质(coupling medium)。如本领域技术人员所知，客户端计算设备232也可以配备调制解调器304，用来通过点对点协议(Point-to-Point)(“PPP”)连接或者串行线Internet协议(“SLIP”)连接来连接到因特网。调制解调器304可以使用电话线连接、电缆连接、无线连接、数字用户线路或者本领域已知的其它类型的通信连接。
客户端计算设备232还包括处理单元302、显示器348和存储器308。存储器308主要包括随机读取存储器(“RAM”)、只读存储器(“ROM”)和永久海量存储设备，如磁盘驱动器。存储器308存储操作系统310，用来控制客户端计算设备232的操作。在本发明的实际的实施例中，操作系统310提供了图形操作环境，如Microsoft公司的WINDOWS图形操作系统，在其中激活的应用程序被表示为带有用户可见的显示的一个或多个图形应用窗口。存储器308还包括网络浏览器234，如Netscape的NAVIGATOR或者Microsoft的InternetExplorer浏览器，用来通过万维网获取旅游管理系统230。可以理解，这些组件可以存储在计算机可读媒质上面，并使用与计算机可读媒质(如软盘、CD-ROM、DVD-ROM或者网络接口300)相关的驱动器机制来载入到客户端计算设备232的存储器308中。存储器308、网络接口300、显示器348和调制解调器304都通过一条或多条总线连接到处理器344单元。就如众所周知的，其它的外围设备也可以用相似的方式连接到处理器单元。
附图4是描绘用于与根据本发明的旅游管理系统230交互的旅游服务器236(附图2)的示例性结构的框图。本领域技术人员会理解，旅游服务器236包括比附图4所示多许多的组件。然而，没有必要把这些广泛使用的通用组件全部显示出来，以公开用来实现本发明的示范性的实施例。如附图4所示，旅游服务器236通过网络接口400连结到因特网20。本领域的普通技术人员会理解，网络接400包括必要的电路，用来把旅游服务器236连接到因特网20，并且构造得可以使用TCP/IP协议，或者其它协议，如IIOP。
旅游服务器236还包括处理单元402、可选的显示器404、输入/输出(“I/O”)端406以及海量存储器408，所有这些设备都通过通信总线，或者其它通信装置，进行连接。海量存储器408通常包括RAM、ROM和永久海量存储设备，如硬盘驱动器、磁带驱动器、光驱动器、软盘驱动器或者它们的结合。海量存储器408存储操作系统410，来控制旅游服务器236的操作。可以理解，这个组件可以包括为本领域普通技术人员所知的通用服务器操作系统，如UNIX、LINUXTM，或者Microsoft WINDOWS NT(圈R)。
海量存储器408也存储程序代码和数据，用来与一个或多个的客户端计算设备232进行接口，用来与一个或多个的因特网提供商240进行接口，用来处理各种目录管理任务，以及用来处理各种预订管理任务。更具体来说，海量存储器408存储客户接口应用程序412，用来通过一个或多个的万维网页与一个或多个的客户端计算设备232进行通信。客户接口应用程序412包括计算机可执行指令，当被旅游服务器236执行的时候，与一个或多个的客户端计算设备232建立起通信信道。客户接口应用程序412的操作将在下面进行详尽的描述。海量存储器408还存储提供商接口应用程序414，用来与一个或多个的提供商通信。提供商接口应用程序414包括计算机可执行指令，当被旅游服务器236执行的时候，与一个或多个的提供商240建立起通信信道。提供商接口应用程序414将在下面进行详尽的描述。
海量存储器408还存储目录处理应用程序416以处理目录，以及预订处理应用程序418以处理预订。目录处理应用程序416和预订处理应用程序418都包括计算机可执行指令，当被旅游服务器236执行的时候，协助管理目录和预订数据。本领域技术人员会理解，这些组件可以被存储在计算机可读媒质上，并使用与计算机可读媒质相关联的驱动机制，如软盘、CD-ROM、DVD-ROM驱动器，或者网络接口400，来载入到旅游服务器236的海量存储器408中。
根据本发明的目录管理方面，旅游管理系统230的旅游服务器236被用于管理来自于客户端计算机232和提供商240的、可获得的目录项目查询和目录项目行为请求。根据这个方面，旅游服务商236获得了对来自于一个或多个的提供商240的各种目录项目的权利。例如，如果目录项目是实际的物品，旅游服务商的服务可以实际地(physically)获得对于该待出售项目的拥有权。如果目录项目不是实际的物品，旅游服务器的服务可以只从提供商240获得对于该旅游服务商出售该物品/服务的权利的认可。
不管目录项目是否是有形的(tangible)，在从各个提供商240处获得各种目录项目之后，旅游服务器236存储描述该目录项目以及它对于消费者的可获得性的数据，该数据通常称为目录项目数据。使用目录项目数据，旅游服务器236可以接受客户端计算机对于可获得的目录项目的查询。此外，旅游服务器236也可以接受关于管理旅游服务器236保存的提供商目录项目的各种任务的提供商信息。
根据本发明，为了协助目录项目数据管理，旅游服务器236使用目录项目数据关系来以各种方式处理目录项目数据。更具体来说，在本发明的一个实施例中，旅游服务器236使用建立起三个明显级别的数据描述的数据关系，来管理目录项目。附图5是三个细节级别目录项目关系500的框图，根据本发明，被旅游服务器236用来管理目录项目。该三个级别的细节形成了这样的层级关系：每个级别都包括有关于旅游服务器236管理的目录项目的各种方面的数据。
总体来说，第一个级别的细节包括与目录项目相关的最广泛的特征数据。第一个级别的细节可能对于一些目录项目来说是相同的。第二个级别的细节与目录项目的第一个级别的细节有关，包括与该目录项目相关的更多具体细节。第二个级别的细节数据不象第一个级别那样广泛，但是也有可能对于一些目录项目是相同的。第三个级别的细节与第一个和第二个级别的细节有关，提供了与目录项目相关的更为具体的数据。第三个级别的细节包括仅限于单个目录项目的数据。
如附图5所示，用来描述一个目录项目的第一个级别的细节是货物保存(stock-keeping)单元(“SKU”)组502纪录。每个SKU组502纪录包括与目录项目相关的最广泛的描述数据。SKU组502数据可以对于一些不同的目录项目通用。然而，并不是每种类型的目录项目都要有SKU组502纪录。用来定义目录项目的第二个级别的细节是SKU 504纪录。每个SKU 504纪录相对应于SKU组502纪录，定义和目录项目有关的更为具体的数据。更具体来说，每个SKU 504纪录对应于可以出售给消费者的一个可识别的产品或服务。因此，SKU 504纪录包含基本级别的细节。类似于SKU组502，SKU 504数据可能和多于一个目录项目相关联。用来定义一个目录项目的第三个级别的细节是SKU目录506纪录。每个SKU目录506纪录对应于一个SKU组506和一个SKU 504纪录，定义与目录项目有关的更为具体的数据。然而，不象SKU组502和SKU 504纪录，SKU目录506数据与单个的目录项目相关联。更具体来说，SKU目录506纪录相当于SKU 504纪录的一个特例(specific instance)。本领域技术人员会理解，在SKU组502、SKU 504和SKU目录506纪录之间的细节的分配可以进行修改。
在对旅馆房间目录项目应用SKU目录项目信息定义的一个示范性例子中，假定目录项目是一部分可在特定日期进行销售的旅馆房间。根据本发明，旅游服务器236根据目录项目数据关系500，存储有关于目录项目的实例(instance)的细节，即在特定日期的旅馆房间。更具体来说，旅游服务器236可以生成对应于第一个级别的细节的SKU组502，如旅馆名称。旅馆SKU组502纪录可以包括对于与该旅馆相关的目录项目来说独特的、最广泛的细节，如总体的旅馆服务费、全旅馆范围内的使用限制以及诸如此类。此外，SKU组502纪录信息还可以包括基于日期的信息，这使得旅游服务器236能够判断取决于使用日期的具体收费、税金、服务费。
之后，旅游服务器236可以生成与SKU组502纪录相关联，并对应于目录项目的第二个级别的细节的一个或多个的SKU 504纪录。例如，旅游服务器236可以为旅馆(SKU组502)中每种类型的房间生成SKU 504纪录，如双人房间、豪华房间(king size room)和顶层套间。旅游服务器236包括在每个SKU 504纪录中的所有房间的具体数据，如每种房间类型的基本价格、所有顶层套房各自的追加收费、房间尺寸、房间使用纪录等。
接下去，旅游服务器236可以生成与SKU组502和SKU 504纪录相关联，并对应于涉及目录项目的第三个级别的细节的SKU目录506纪录。每个SKU目录506纪录包括描述目录项目，即待售的旅馆房间，的具体特征的数据。这个信息可以包括来自于提供商240的房间价格、向消费者收取的房间价格、使用限制。此外，该信息还可以包括来自提供商的限制，如可以向消费者收取的最高价格、预订必须提前的时间等。参考前面的例子，如果一个提供商240分配了2001年7月28日的20个双人房间，旅游服务器236可以生成SKU目录506纪录，与旅馆SKU组502和双人房间SKU 504都相关联，并包括规定存在日期2001年7月28日以及可获得20个房间的数据。采用类似的方式，如果该提供商240分配给旅游服务器236第二晚(即，2001年7月29日)的同样一批房间，将生成一个新的SKU目录纪录506，它具有规定存在日期为2001年7月29日以及可获得20个房间的数据。在这个例子中，两个SKU目录纪录都会被链接到同一个SKU组502纪录和SKU 504纪录上。
在将SKU目录项目信息应用到一个音乐家的音乐汇编的另一个示范性例子中，假定目录项目是旅游服务器236(或者任何配置成销售音乐相关物品的服务器)销售的涉及特定音乐家的一些唱片、磁带、光盘(“CD”)以及数字视频光盘(“DVD”)。为了存储目录项目数据，旅游服务器236能够生成一个对应于第一个级别的细节的SKU组502纪录，如音乐提供商或者特定音乐商标。之后，旅游服务器236能够生成一些SKU 504纪录，对应于第二个级别的细节。在本实施例中，旅游服务器236能够为用来销售的每种类型的产品生成一个SKU 504纪录。例如，旅游服务器236能够为提供商提供的每个不同的唱片生成一个影集SKU纪录，为提供商提供的每个不同的磁带生成一个磁带SKU纪录，为提供商提供的每个不同的CD生成一个CD SKU纪录，为提供商提供的每个不同的DVD生成一个DVD SKU纪录。最后，旅游服务器236能够为SKU 504纪录的每个特例生成SKU目录506纪录。例如，如果提供商分配了两批配额的同样特征(distinct)的CD来出售，旅游服务器236可以生成两个涉及CD SKU 504纪录的SKU目录506纪录，来对应提供商的每批配额。每一个这些SKU目录506纪录可以包括提供给旅游服务器236的每批配额的数目。本领域技术人员会理解，目录项目数据关系500也可以被提供给各种其它的目录类型，包括但并不限于，航空服务、航船服务、比赛门票、物品出租以及诸如此类。此外，本领域技术人员会理解，一些目录项目可以不使用全部的三个级别细节，或者，根据本发明，也可以使用更多的或者不同级别的细节。
如前所述，根据本发明的一个方面，旅游服务器236可以被用来执行多种目录管理任务。附图6以及10-12是附图2的旅游管理系统230的框图，显示了根据本发明，可以被旅游管理系统执行的各种目录管理任务。参考附图6，与本发明的一个方面相一致，旅游管理系统230可以被用来接受客户端计算设备232对可获得的目录的查询。在本发明的一个示范性实施例中，消费者可以在客户端计算设备232上使用网络浏览器234来浏览旅游服务器236提供的网站。例如，消费者可能对于获取关于可乘坐的航班的信息感兴趣。这样，消费者不需要发出预订请求，而是可以仅仅把通信限于对可获得性、价格、选择数目等的查询。
如附图6所示，客户端计算设备232发出一个对于目录项目的用户查询。该对于目录的用户查询通过通信网络，如因特网20，被发送，并被旅游服务器236接收。旅游服务器236向目录存储器238发出查询，目录存储器238根据目录项目数据关系500和匹配的查询标准返回目录项目数据。旅游服务器236通过通信信道，把查询的结果发送给客户端计算设备232。
附图7是显示目录请求处理程序700的框图，根据本发明，该请求处理程序700由旅游服务器236执行，以处理附图6中描述的对于目录项目的查询。在方框702，旅游服务器236的客户接口应用程序412获取对于可获得的目录项目的用户查询。在本发明的一个实施例中，对于目录的用户查询包括一组标准，可以被用来识别存储在目录存储器238中的相应的目录项目数据。如果目录在很多天都可获得的话，这组标准可以包括可用的日期范围。这组查询标准还可以包括各种的目录具体标识(identifier)，例如对于旅馆、航空、航海和它们的组合的选择。这组查询标准还可以包括对于特定类型的目录项目的偏好的选择。例如，这组标准可以包括对于航班上座位类型(如，窗口、过道、一等舱)，旅馆房间类型，船舱类型，吸烟爱好，特别就餐要求，娱乐设施，靠近附加娱乐设施以及诸如此类的选择。这组标准此外可以包括对于特定产品的识别，例如书的标题、产品代码、订单号码等。此外，这组标准可以包括一个或多个预先存储的用户偏好，它可以帮助从目录存储器238中选择匹配的目录项目。例如，用户可以配置用户计算设备232，来在每月的开始时候发出对于特定航班的目录项目查询。
此外，在本发明的一个实施例中，旅游服务器236可以为客户端计算设备232提供一个或多个的图形用户界面(“GUI”)，允许消费者通过操作图形对象来指定对于目录项目选择标准的选择。例如，旅游服务器236可以提供允许消费者在一个月的时间段内选择日期或者感兴趣的日期范围的日历图形对象。
在方框704处，旅游服务器236的目录处理应用程序416从目录存储器238中查询可获得的目录。附图8是根据本发明，被目录处理应用程序416执行的查询可获得的目录的子程序800的流程图。在方框802处，目录处理应用程序416从客户接口应用程序412获得一组用户规定的标准。在本发明的一个实施例中，目录处理应用程序416也可以处理输入标准，来生成附加选择标准。例如，如果用户计算设备232输入所选择的日期或者日期范围，目录处理应用程序416也可以生成待搜索的日期附加范围或者日期组合。
在方框804，目录处理应用程序416搜索匹配该组标准的任何SKU组502纪录。在方框806，目录处理应用程序416搜索匹配该组标准并对应于该SKU组502纪录的任何SKU 504纪录。。在方框808，目录处理应用程序416搜索匹配该组标准并对应于该SKU组502纪录和SKU 504纪录的任何SKU目录506纪录。
在判决框810，进行一个测验来判断是否有多条匹配的SKU目录506纪录。根据本发明的一个实施例，对于一个特定的SKU 504，可以存在多条匹配的SKU目录506纪录。例如，基于先前来自提供商240的配额，目录存储器238可以具有：为具有第一种价格的旅馆房间类型(如双人房间)而设的第一个SKU目录506，以及为具有第二种价格的同样的旅馆房间类型而设的第二个SKU目录506。因此，有可能需要目录处理应用程序416来判断哪个SKU目录506项目同提交的标准最为匹配。如果有多个SKU目录506纪录，目录处理应用程序416在方框812对多个SKU目录506纪录进行限定(qualify)。在本发明的一个实施例中，对于SKU目录506纪录的限定包括对于可以应用的SKU目录506纪录的选择。例如，如果SKU目录506纪录对应于一个具有对于消费者使用的限制(consumer limitation of use)(如必须与特定航班的机票一起销售或者作为打包的服务(package)中的一部分来销售)的目录项目，并且该要求标准不满足使用限制，目录处理应用程序416不会选择该SKU目录506纪录。类似地，如果匹配的SKU目录506纪录包括提供商对使用的限制(如来自于第一批配额的目录项目必须比来自于第二批配额的目录项目先出售)，目录处理应用程序416不会选择对应于第二批配额的目录项目的SKU目录506纪录。然而，对于SKU目录506纪录的限定也可以包括对于其它不受限制的SKU目录506纪录的选择，而不用必须选择单一的匹配SKU目录506纪录。
在方框812完成之后，或者如果在判决框812没有多条匹配的SKU目录506纪录，那么在判决框814，会进行一项测试来判断是否还有其它匹配的SKU组502纪录。如果还有其它的SKU组502纪录，在方框816，目录处理应用程序416检索到下一个匹配的SKU组502，子程序800回到方框806。可以不断重复方框806-816，直到在方框804识别出的所有匹配的SKU组502纪录都得到处理。此外，尽管检索和限定的处理步骤显示得好像是分离的处理，本领域技术人员会理解，所有的SKU组502、SKU504以及SKU目录506纪录可以在单次处理中进行检索和限定。
如果没有其它匹配的SKU目录506纪录，目录处理应用程序416在方框818，处理并返回在方框804-812中识别的SKU信息数据。在本发明的一个实施例中，可以对目录处理应用程序416进行处理(beprocessed)，以生成对于对应于SKU信息的每个选择的目录项目的总价格。在本发明的另一个实施例中，该处理可以包括判断对应于SKU信息的目录项目是否可以获得。此外，目录处理应用程序416可以使用一个或多个的处理方法，根据按照对消费者的价格或者其它因素进行分类的匹配的SKU信息，来生成目录项目订购清单。例如，如果请求标准包括优先(preference)标准(比如，对于对应于用户的频繁飞行计划的航线)，目录处理应用程序416可以选择显示匹配该特性的SKU目录506纪录，作为显示给用于的第一条项目。用来基于消费者价格来建立定购清单的处理方法和系统的一个例子在美国专利申请No。09/825,451中被公开，标题是《OPTIMIZED SYSTEM ANDMETHOD FOR FINDING BEST FARES》，该专利申请于2001年4月4日提交，在此处引述作为参考。然而，本领域技术人员会理解，本发明可以使用备选的或者其它的匹配目录数据处理方法。此外，根据本发明，目录处理应用程序416也可以生成不同的图形或文本屏幕显示，用来显示在客户端计算设备232上。例如，旅游服务器236可以移植(populate)一个带有可获得的目录项目的日期范围的日历GUI。在方框820，子程序800返回程序700。
回到附图7，在方框706，客户接口应用程序412获得来自于目录处理应用程序416的结果，并将处理的目录数据结果(如，SKU信息)发送给客户端计算机232。在方框708，程序700结束。
附图9是显示被旅游服务器236的目录处理应用程序416使用，以处理客户端计算设备232发出的可获得目录查询的数据关系的框图。在本发明的一个实施例中，目录处理应用程序416可以作为处理引擎900，来获得并处理各种数据块。如附图9所示，处理引擎900获得根据目录项目数据关系500存储并涉及用户查询902的一个数据块。基于和用户查询902相联系的一组标准以及处理方法，例如上面描述过的、附图7和8中显示的程序700和800，处理引擎900获得一个或多个块的目录项目数据500。除了用户查询902以及目录项目数据500，处理引擎900还可以获得涉及一个或多个的并不与特定的目录项目数据500直接相关的外部调整的数据块904。例如，调整数据块904可以包括涉及用户特定折扣、媒介特定折扣(如，使用因特网来处理请求)、非目录项目相关的服务费、税率、高级(advanced)购买折扣、用户历史价格调整、保持价格调整的长度(length of stayadiustments)、特殊价格代码，以及诸如此类。之后，使用用户查询数据902、目录项目数据500和调整数据904数据块，处理引擎900处理目录项目数据，生成一组处理结果906，如同上面关于方框818的解释(附图8)。之后，处理结果可以被目录处理应用程序416发送到客户接口应用程序412，以发送给客户端计算设备232。本领域技术人员会理解，附图9的数据框是用于示范性的目的，可以在本发明的范围之内对其进行修改。
参考另一个目录管理任务，附图10是附图2的旅游管理系统230的框图，显示根据本发明由旅游服务器236发起的、对于新的目录的请求。在本实施例中，旅游服务器236通过通信网络，例如因特网20，向提供商240生成对于目录的请求。提供商240通过查询提供商目录存储器241，处理旅游服务器236请求。提供商目录查询的结果被送回到提供商240，之后通过通信网络20发送给旅游服务器236。之后，旅游服务器236根据从提供上240收到的应答来修改相应的目录项目。在本发明的一个实际实施例中，与旅游服务器236和提供商都相关联的用户可以通过基于网络的控制来发起行动(action)。此外，旅游服务商236计算系统不需要直接与提供商240计算系统集成在一起，比如通过存取提供商数据库41(241？)或者任何其它的提供商应用程序。相反，双方的交互可以仅需要数据信息的交换。
附图11是附图2的旅游管理系统230的框图，显示了提供商发起的目录修改请求。与附图10的框图相类似，本实施例涉及对于旅游服务器236存储在目录存储器238中的目录数据的修改。如附图11所示，提供商240通过通信网络，如因特网20，发起目录修改请求。在本发明的一个实施例中，提供商代理可以通过提供商240计算系统或者旅游服务器236提供的网页界面，来生成目录修改请求。旅游服务器236接收目录修改请求。在一个实施例中，旅游服务器236不要求接受提供商发送的目录修改请求。然而，假定至少一部分修订请求对于旅游服务器236是可接受的，旅游服务器236处理目录修改请求，根据包含在目录修改请求中的信息修改目录存储器238。之后，旅游服务器236通过通信网络20，向提供商240发出一个目录修改确认。本领域技术人员会理解，在一些实施例中，可以要求旅游服务器236接受全部的修改请求。
附图12是附图2的旅游管理系统230的框图，显示了提供商对于目录状态的请求。如附图12所示，提供商240通过通信网络，如因特网20，发起目录状态查询。旅游服务器236接收到目录状态查询，并查询目录存储器238。目录存储器238返回匹配提供商查询的目录项目数据。如同下文中将详细描述的，旅游服务器236有滤除一部分从目录存储器238接收的目录项目数据的选择权。之后，旅游服务器236可以通过通信网络20，把目录项目数据发送给提供商240。
附图13是显示提供商目录请求处理程序1300的流程图，该程序1300被旅游服务器236用来协助不同的提供商240行为请求，如附图10、11和12中显示的提供商目录行为。在方框1302，旅游服务器236的提供商接口应用程序414获得提供商对于目录行为的请求。在方框1304，目录处理应用程序416处理提供商对于目录行为的请求。在本发明的一个实施例中，目录处理应用程序416可以执行一个或多个的涉及提供商对于目录行为的不同请求的子程序。
例如，附图14是显示根据本发明，被旅游服务器236的目录处理应用程序416执行的处理提供商批量目录行为请求的子程序1400的流程图。在方框1402，目录处理应用程序416从提供商接口应用程序414获得提供商批量目录行为请求。在本发明的一个实施例中，提供商批量目录行为请求包括传送对于表示有待被目录管理系统出售的一个或多个的目录项目的配额的数据。提供商批量目录行为请求也可以包括被提供商发送，以修改现存的批量目录配额的信息。此外，提供商批量目录行为请求还可以包括来自于新的或者现有的提供商240对于目录项目的新的配额。
在方框1404，目录处理应用程序416识别匹配批量目录行为请求SKU组502、SKU 504和SKU目录506纪录。在本发明的一个实施例中，批量目录请求可以直接指先前存在的SKU组502、SKU 504和SKU目录的实例。或者，行为请求可以请求生成一个新的SKU目录506纪录。在判决框1406，进行一个测试来判断是否存在匹配批量目录行为请求的SKU组、SKU和SKU目录纪录。如果不存在，在方框1408，目录处理应用程序416生成相应的SKU组、SKU和/或SKU目录纪录。例如，如果提供商240发出包含具有与前一配额具有不同价格的新的旅馆房间配额的批量目录行为，目录管理系统36会生成对应于新的配额的一个新的SKU目录506纪录。然而，如果SKU组或SKU纪录已经存在，目录处理应用程序416不会生成新的SKU组或SKU纪录。
如果在方框1406有一个匹配的SKU目录506纪录，或者一旦SKU目录506纪录被生成，目录处理应用程序416使用批量目录行为请求更新匹配的SKU目录纪录。在本发明的一个实施例中，这可以包括使用提供商240分配的目录项目数量，移植(populating)一例新的SKU目录纪录。或者，信息的更新可以包括，根据批量目录行为请求的增或减，来调整在SKU目录纪录中描述的目录项目配额。此外，信息的更新可以包括调整其它的目录项目特征，如目录项目的价格、使用限制等。在方框1412，目录处理应用程序416返回对批量目录行为请求的确认，它将被返回到提供商240。在方框1414，子程序1400返回到程序1300。
在另一个例子中，附图15是旅游服务器236的目录处理应用程序416使用的处理提供商目录查询行为子程序1500的流程图，作为对于方框1304(附图13)的另一个可选的子程序。在方框1502，目录处理应用程序416从提供商接口应用程序414获得提供商目录行为请求。提供商目录行为请求包括一组标准。在方框1504，目录处理应用程序416识别匹配提供商目录查询请求的SKU组、SKU和SKU目录纪录。在步骤1506，目录处理应用程序416滤出匹配提供商目录查询请求的SKU组、SKU和SKU目录纪录。在本发明的一个实施例中，包含在SKU组、SKU和SKU目录纪录中的一些数据可能不会被发放给提供商。例如，尽管提供商240可以知道分配目录时所确定(issued)的价格，旅游服务商236不会希望提供商知道以什么价格将其卖给了消费者。因此，目录处理应用程序416可以在将其发送给提供商之前将这部分数据滤除。在方框1508，目录处理应用程序416返回滤出匹配提供商目录查询请求的SKU目录纪录。在本发明的一个实际实施例中，发送的数据可以包括使用数据(utilization data)，使用数据不仅包含SKU目录506纪录中特定数目的可获得的目录项目，而且包括一些类型的历史，这可以使得提供商240能够监控目录被使用的进展。本领域技术人员会理解，这使得提供商240可以实时监控旅游服务器售出的目录项目的数目。随后，实时数据可以被用来作为准备，如必要的材料，和/或允许提供商根据特定目录项目的销售行为来调整没有售出的目录的价格(如附图14的程序1400所示)。
返回附图13，在方框1304中，一旦目录处理应用程序416已经执行了各种提供商目录行为子程序(如，附图14和15)，在方框1306，请求处理的结果被发送到提供商240。在本发明的一个示范性实施例中，这个结果可以包括对于行为已完成的确认。这个结果也可以包括修改目录行为的数据，这样提供商可以据此修改其纪录。在方框1308，程序1300终止。
为了完成数据管理并执行上述程序，旅游服务器236可以根据关系数据库数据存储格式，在数据存储器238中存储目录项目数据。附图16是显示根据本发明，用于存储目录数据的相关数据库数据关系1600的框图。在本发明的一个实施例中，数据关系1600可以被定制化，以包括对应于特定目录项目的独特方面(如，与旅馆房间目录项目相关的床的类型)的一个或多个的数据表格或数据字段(field)。然而，本领域技术人员会理解，根据本发明，也可以使用其它的数据存储形式或者其它的相关数据库数据关系。
如附图16所示，数据关系1600规定了SKU组表格1602，可进行操作以包括涉及SKU组502纪录(附图5)的目录项目数据。在本发明的一个实际实施例中，SKU组表格1602可以包括SKU组数据1604，如SKU组ID、卖主标识、物品地址、纳税地区识别码、SKU组联系信息以及诸如此类。此外，根据相关数据库，SKU组数据1604中的一个或多个的字段可以指向一个或多个的附加数据表格，以进一步定义SKU组数据1604，如1606所示。
数据关系1600也定义了一个SKU表格1608，可进行操作，以包括涉及SKU 504纪录(附图5)的目录项目数据。在本发明的一个实际实施例中，SKU表格1608可以包括SKU数据1610，如SKU组ID字段、单元类型信息、取消处罚信息、服务收费信息、特别人员信息和预订信息，以及诸如此类。类似于SKU组表格1602，在SKU数据1610中，一个或多个的字段可以指向一个或多个的附加数据表格，以进一步定义SKU数据1610，如1612所示。
继续参考附图16，数据关系1600此外定义了一个SKU目录表格1614，可进行操作，以包括涉及SKU目录506纪录(附图5)的目录项目数据。在本发明的一个实际实施例中，SKU目录表格1614可以包括SKU目录数据1616，如SKU ID字段、质量字段、提供商价格信息、消费者价格信息、目录使用信息、使用限制信息、附属信息，以及诸如此类。此外，在SKU目录数据1616中，一个或多个的字段可以指向一个或多个的附加数据表格，以进一步定义SKU目录数据1616，如1618所示。
除了管理目录，旅游管理系统230的旅游服务器236可以被用来管理来自于一个或多个的客户端计算设备232的预订请求。本领域技术人员会理解，预订请求可以包括预订对于一项服务的权利(如，在某个夜晚留在一间旅馆房间里的权利)的提议(offer)。然而，预订请求也可以包括购买或者传递对于实际的物品的权利的提议(offer)(如，购买一本书的提议)。此外，旅馆服务器236可以用来向客户端计算设备232和提供商240发送相应的信息。为了协助预订请求处理，旅游服务器236使用预订数据关系来存储和管理处理预订请求所需要的数据。
附图17是根据本发明，被旅游服务器236的预订处理应用程序418使用，来管理预订请求的预订数据关系1700的框图。如附图17所示，客户端计算设备232(应当为旅游服务器236？)接收到的预订请求可以被三个级别的细节来特征化。用来描述预订请求的第一个级别的细节是预订交易1702纪录。每个预订交易1702纪录可以与一个或多个的预订请求相关联，并可以被用来跟踪来自于一个用户或者集合在一起的一组用户的多个预订请求。
用来定义预订请求的第二个级别的细节是预订项目1704纪录。每个预订项目1704纪录对应着一个预订交易1702纪录，并定义与一个特定预订请求相关联并具有共同特征(如，共同的卖主、共同的预订号码等)的一个或多个的目录项目。例如，假定通过预订请求，用户要求在一间旅馆逗留三天，购买机票(airfare)和租用汽车两天。旅游服务器236可以生成对于旅馆预订、机票预订和租赁汽车预订的预订项目1704纪录。尽管附图17中只显示了一个预订项目1704纪录，本领域技术人员会理解，任何数据的预订项目1704都可以指向一个预订交易1702纪录。
被用来定义预订请求的第三个级别的细节是一个或多个的预订目录1706纪录。每个预订1706纪录对应着一个预订项目1704纪录，并与和预订请求相关的目录项目的一个特例相关联。参考前面的例子，旅游服务器236可以生成三个与旅馆预订项目1704纪录相关联的预订目录1706纪录，对应逗留的每一晚；两个与机票预订项目纪录相关联的目录项目纪录，对应着往返的飞行；以及两个与租赁汽车目录项目纪录相关联的预订目录纪录，对应着两天的租赁汽车预订。在本发明的一个实施例中，每个预订目录1706纪录都与一个SKU目录506(附图5)相关联，并包括涉及目录项目的特例的预订数据。然而，在一些例子中，预订目录1706纪录可以为在SKU目录506纪录的范围之外的附加目录项目(如，超额预订的配额)而生成。
继续参考附图17，预订数据关系也包括一个或多个的价格组件1708，价格组件1708包含涉及对于预订请求的各个方面的消费者价格。此外，在本发明的一个实施例中，价格组件1708可以同预订交易1702、预订项目1704以及预订目录1706纪录关联起来。例如，价格组件1708可以与预订目录1706纪录相关联，并且可以包括和对于预订目录项目的一个实例的消费者价格相关的数据。另一个价格组件1708可以与预订项目1704纪录相关联，并可以包括与预订项目级别相关的价格数据，例如对于打包(package)的预订的价格调整。此外，价格组件1708可以与预订交易组件1702相关联，并可以包括与预订交易级别相关的数据，例如对于员工折扣、基于网络的预订请求等等的价格调整。如下文所述，不同的价格组件1708数据可以组合在一起，用于生成预订请求的总的消费者价格。
本领域技术人员会理解，预订数据关系1700可以被用于多个目录项目预订请求，包括但不局限于旅馆预订，航空预订，航船预订，票务预订，租赁资产预订，实物出售或者出租，以及诸如此类。此外，本领域技术人员会理解，对于特定预订请求的处理可以不使用预订数据关系1700中全部三个级别的细节。
如前所述，根据本发明的一个方面，旅游服务器236可以被用来完成多种预订请求处理任务。附图18和19是附图2的旅游管理系统230的框图，显示了根据本发明，涉及预订请求处理的各种实施例。参考附图18，与本发明的一个方面相一致，旅游管理系统230可以被用来获得和处理客户端计算设备232预订请求。如附图18所示，客户端计算设备232发出用户预订请求。用户预订请求通过通信网络，如因特网20，被发送，并被旅游服务器236接收。旅游服务器236向目录存储器发出查询，目录存储器返回根据目录项目数据关系500存储、并匹配查询标准的目录项目数据。此外，旅游服务器236根据预订数据关系1700生成预订数据。旅游服务器236处理用户预订请求、目录数据和预订数据。如果预订处理成功，旅游服务器236通过因特网20发给用户端计算设备232一个确认，并发给一个或多个的提供商240对于预订的目录项目的通知。
参考附图19，旅游管理系统230可以被用来处理客户端计算设备232对于不持续连接在旅游管理系统230上的提供商240的预订请求。与附图18相类似，客户端计算设备232发出用户预订请求。用户预订请求通过通信网，如因特网20，被发送，并被旅游服务器236接收。旅游服务器236向目录存储器238发出查询，目录存储器238返回根据目录项目数据关系500存储、并匹配查询标准的目录项目数据。此外，旅游服务器236根据预订数据关系1700生成预订数据。旅游服务器236处理用户预订请求、目录数据和预订数据。如果预订处理成功，旅游服务器236发给提供商240一个提供商通知，例如通过传真等。提供商240获得通知，并向旅游服务器236确认预订。随后，旅游服务器236向客户端计算设备232发送确认。
附图20是显示目录请求处理程序2000的流程图，根据本发明，该程序由旅游服务器236执行。在方框2002，旅游服务器236的客户接口应用程序412获得用户预订行为请求。在本发明的一个实施例中，用户预订行为请求可以包括对于新预订的请求、取消现有预订的请求以及修改现有预订的请求。然而，本领域技术人员会理解，行为请求可以包括附加的涉及预订的行为。在方框2004，旅游服务器236的预订处理应用程序418处理预订行为请求。因此，根据用户预订行为请求，预订处理应用程序418可以执行不同的处理子程序。
在第一个示范性例子中，附图21是处理新的预订请求子程序2100的流程图，根据本发明，该子程序由预订处理应用程序418来执行，以处理新的消费者预订请求。在本发明的一个实施例中，和用户对于可获得的目录的查询(附图7的方框702)相类似，由客户接口应用程序412获得、并传送到预订处理应用程序418的用户预订请求包括一组标准，用来识别存储在目录存储器238中、并匹配一组用户规定标准的目录数据。如果该目录在多个日期存在，那么这组标准可以包括使用的日期或者日期范围。这组标准也可以包括不同的目录特定标识(identifier)，如对旅馆、航空、航海及其组合的选择。这组标准还可以包括对于特定类型的目录项目的优先选择。例如，这组标准可以包括对于航班座位类型(如，窗口、过道、头等舱)、航班上的特定座位、旅馆房间类型、旅馆中的特定房间、船舱类型、航船上的特定船舱、吸烟偏好、特殊用餐要求、娱乐设施、靠近娱乐设施等等，的选择。此外，这组特定标准可以包括对于特定产品的识别，例如书的标题、产品代码、订单号码等。此外，这组标准可以包括一个或多个预先存储的用户偏好，它可以帮助从目录存储器238中选择匹配的目录项目。例如，旅游服务器236可以存储涉及用户对于目录的要求的这组标准，如果用户以后要求预订的话，可以再次使用同一组标准。
在方框2102，预订处理应用程序418从客户接口应用程序412获得一组用户规定的标准。预订处理应用程序418查询匹配这组标准的SKU组502、SKU 504和SKU目录506纪录，并从SKU目录506配额中减去预订请求的数量。例如，如果预订请求包括在某旅馆逗留两个夜晚的请求，预订处理应用程序418为每个晚上选择匹配的SKU目录560纪录，并在房间配额中将每个SKU目录纪录减一。在本发明的一个示范性实施例中，预订处理应用程序418可以使用例如查询可获得目录的子程序800(附图8)的处理过程(process)。或者，根据本发明，预订处理应用程序418也可以通过目录处理应用程序416获得事先得到的目录数据。
在本发明的一个实施例中，旅游服务器236可以同时处理多个预订请求。因此，为避免预订目录项目的同一个实例，预订处理应用程序418将从目录存储器238获得的目录项目信息设置成锁定状态。在本发明的一个实施例中，预订处理应用程序418向包含先前从SKU目录纪录506中取出的SKU目录506目录项目信息的锁定表格添加纪录。参考前面的例子，预订处理应用程序418将对应于旅馆房间每个晚上的SKU目录506纪录数据放在锁定表格中。这样，尽管在锁定表格中描述的目录项目还没有被预订，它们至少被临时从可获得的目录中取出。本领域技术人员会理解，本发明也可以使用其它的目录项目预订数据管理办法/指示器。
在方框2104中，预订处理应用程序418生成预订交易1702纪录、一个或多个预订项目1704纪录以及一个或多个预订目录1706纪录的实例。类似于目录项目纪录，预订交易1702、预订项目1704以及预订目录1706也被锁定。在方框2106，预订处理应用程序2106完成财务交易。在本发明的一个实施例中，预订处理应用程序418获得与预订交易1702、预订项目1704以及预订目录1706纪录相关联的价格组件1708(附图17)，并试图完成财务交易。财务交易的完成可以包括获得信用卡信息并产生收费。财务交易的完成也可以包括获得支票账户信息并产生收费。本领域技术人员会理解，本发明也可以使用其它的财务交易方法，包括但并不限于：预付费账户，第三方交易提供商，以及诸如此类。
在判决框2108，进行一项测试来判断财务交易是否成功完成。如果交易没有成功，或者财务交易无法在限定时间内证实，在方框2110，预订交易1702、预订项目1704以及预订目录1706纪录被删除。在方框2112，预订处理应用程序418恢复存储在锁定表格中的SKU目录506纪录信息。更具体来说，预订处理应用程序418把存储在锁定表格中的目录项目数据重新添加到相应的SKU目录506纪录中，以允许恢复目录项目。随后，预订处理应用程序418删除锁定表格中相应的目录项目。在方框2114，子程序2100带着指示交易失败的结果返回程序2000的方框2004。
回到判决框2108，如果财务交易成功，在方框2116，预订交易1702、预订项目1704以及预订目录1706被更新，以表示交易成功。在方框2118，存储在锁定表格中的目录项目信息被删除。此外，SKU目录506使用信息可被更新，以表示目录项目的成功预订。在方框2114，子程序2100带着指示交易成功的结果返回到程序2000的方框2004。
附图22是显示旅游服务器236的预订处理应用程序418使用的数据关系的框图，用来处理客户端计算设备232发出的新的预订请求。在本发明的一个实施例中，预订处理应用程序418可以作为处理引擎2200，来获得并处理不同的数据块。如附图22所示，处理引擎2200获得与匹配用户预订请求的目录项目相关联的、涉及用户预订请求2202的数据块，以及涉及目录数据2204的数据块。
如对方框2104所描述的，处理引擎2200生成对应于用户预订请求2202和目录数据2204的预订交易1702纪录、一个或多个预订项目1704纪录以及一个或多个预订目录1706纪录。此外，如附图22所示，处理引擎也可以生成，或者获得，一个或多个的预订旅游者数据块2206(取决于旅游者的数目以及对于旅游者信息的要求)，可操作用来定义一个或多个的消费者规定的偏好。因此，处理引擎2200生成并随后使用与预订交易1702纪录、一个或多个预订项目1704纪录以及一个或多个预订目录1706纪录相关联的数据，用来处理预订请求。
使用用户预订请求数据2002、目录项目数据2004、预订数据1700以及预订旅游者2004数据块，处理引擎2200随后处理预订请求，并生成不同的结果，其结果可以被预订处理应用程序418发送到客户端计算设备232和/或相应的提供商240。本领域技术人员会理解，附图22的数据图表是用于示例的目的，在本发明的范围内也可以使用其它替代。
在另一个示范性例子中，附图23是处理预订取消请求子程序2300的流程图，根据本发明，由预订处理应用程序418执行，以取消已存在的消费者预订请求。在方框2302，预订处理应用程序418获得对应于预订修改请求的所有的预订交易1702、预订项目1704和预订目录1706纪录(“预订纪录”)。在一个实施例中，由客户接口应用程序412获得，并传送到预订处理应用程序418的用户预订行为请求包括：对应于取消请求的、用来识别预订交易1702、预订项目1704和预订目录1706纪录的数据。例如，用户预订行为请求可以包括识别预订号码、确认号码、与预订相关的用户姓名和/或其它识别标准的数据。此外，在本发明的一个实施例中，用户预订行为请求可以请求仅取消先前的预订的一部分。为了验证部分预订取消是否可行，预订项目1704和/或预订目录1706可以包含取消信息，作为纪录数据的一部分。
在方框2304，预订处理应用程序418将涉及取消请求的目录项目信息放在目录项目信息锁定表格中。类似于对方框2102(附图21)所描述的，锁定表格提供了一种机制，可以管理既不是可获得的目录的一部分，又不是已确认的预订的一部分的目录项目数据。在方框2306，预订处理应用程序418锁定预订纪录。此外，预订处理应用程序418更新预订纪录，就如同处理取消请求成功一样。
在方框2308，预订处理应用程序试图完成财务交易。在本发明的一个实施例中，预订处理应用程序418试图将消费者支付的价格减去取消罚款之后归还给用户。例如，预订处理应用程序418可以尝试归还到用户购买时使用的财务机构信用账户。在一个实施例中，如果无法取消，比如由于已经声明的取消政策，预订处理应用程序418可以在试图取消预订交易1702、预订项目1704和预订目录1706纪录的时候，返回一个错误信息。或者，预订处理应用程序418可以在它试图完成财务交易的时候返回一个错误信息。
在判决框2310，进行一项测试来判断财务交易是否成功。如果财务交易成功，在方框2312，预订处理应用程序418将预订纪录解除锁定。在方框2314，预订处理应用程序418更新对应于锁定表格中的目录项目纪录的所有的SKU项目506纪录。例如，如果预订取消请求涉及在旅馆的一个夜晚，预订处理应用程序418将会在对应于特定旅馆房间目录项目的SKU目录506纪录中增加一个可获得字段。此外，预订处理应用程序418更新相应的SKU目录506使用信息。最后，预订处理应用程序418删除锁定表格中对应于已取消的目录项目的所有的目录项目信息。在方框2316，子程序2300返回到程序2000的方框2004。
返回到判决框2310，如果财务交易不成功，或者如果取消请求无法处理，在方框2318，预订处理应用程序418返回预订纪录，以反映在未成功的取消请求之前的预订纪录的状态。此外，预订处理应用程序418解锁预订纪录。在方框2320，预订处理应用程序418删除锁定表格中对应于涉及取消请求的目录项目的目录项目信息。在方框2316，子程序2300返回到程序2000的方框2004。
在另一个示范性例子中，附图24A和24B是处理预订修改请求子程序的流程图，根据本发明，由预订处理应用程序418来执行，以修改已存在的消费者预订请求。参考附图24A，在方框2402，预订处理应用程序418获得对应于修改请求的新的预订部分的SKU组502、SKU 504和SKU目录506目录项目信息，并锁定目录信息。在本发明的一个实施例中，预订处理应用程序418将目录项目信息放在锁定表格中。类似于对方框2102(附图21)的讨论，预订处理应用程序418从客户接口应用程序412获得一组用户规定的标准，并识别相应的SKU目录506信息。
在方框2404，预订处理应用程序418获得对应于来自于修改请求的取消部分的预订纪录的目录项目信息。预订处理应用程序418把目录项目信息放在锁定表格中。因此，锁定表格包括涉及被预订的新的目录项目(方框2402)以及被退回到目录存储器238的目录项目(方框2404)的目录项目信息。
在方框2406，预订处理应用程序418锁定预订纪录。此外，预订处理应用程序418更新预订纪录，就如同处理取消请求成功。在本发明的一个实施例中，对于预订交易1702、预订项目1704和预订目录1706纪录的更新可能取决于修改涉及单个还是多个提供商240。如果交易涉及多个提供商240，预订处理应用程序418标记对应于修改请求的取消部分的、旧的预订项目1704和预订目录1706纪录，并将预订交易1702、预订项目1704更新为成功取消。此外，预订处理应用程序418生成对应于修改请求对于原来的预订交易1702纪录的新的预订部分的、新的预订项目1704和预订目录1706纪录。如果交易涉及单个提供商240，预订处理应用程序418把修改请求的取消部分的原有预订交易1702、预订项目1704和预订目录1706纪录，同修改请求的新的部分的预订交易1702、预订项目1704和预订目录1706纪录关联在一起。因此，提供商240将仍旧保留具有所有的预订信息的单个纪录，或者关联纪录。
在方框2408，预订处理应用程序418试图完成财务交易。在本发明的一个实施例中，预订处理应用程序418将财务交易作为在从目录的退回中归还的金额(减去取消/修改罚款)和对于新预订的收费金额之间的净交易来处理。或者，财务交易也可以分别按照债权和债务来独立地处理。
在判决框2410，进行一项测试来判断财务交易是否成功。现在参考附图24B，如果财务交易成功，在方框2412，预订处理应用程序418将预订纪录解除锁定。在方框2414，预订处理应用程序418更新SKU项目506纪录。类似于方框2118(附图21)，SKU目录506使用信息可能被更新，以指示目录项目预订的成功。最后，预订处理应用程序418删除锁定表格中对应于修改请求的新预订部分的目录项目信息。预订处理应用程序418把与修改请求的取消部分相关的目录项目信息删除，并合并到目录存储器238。如上面对方框2316(附图23)所讨论的，与取消部分相关联的目录信息被合并到目录存储器238中，等待被旅游服务器236出售。在方框2416，子程序2400返回到程序2000的方框2004。
返回到判决框2410，如果财务交易不成功，在方框2418，预订处理应用程序418返回与修改请求的新预订部分相关联的预订纪录。在前面关于方框2318(附图23)已经讨论过预订纪录的返回。在方框2420，预订处理应用程序418删除锁定表格中对应于修改请求的取消部分的目录项目信息。此外，SKU目录506使用信息可以被更新，以显示目录项目的成功预订。在方框2416，子程序2400返回到程序2000的方框2004。
返回到附图20，在方框2006，预订处理应用程序418生成对客户端计算设备232的确认信息，以及对相应的提供商240的通知。在一个实施例中，如附图18所示，客户接口应用程序266从预订处理应用程序418获得确认信息，并通过通信网络20把确认信息发送给用户。或者，如果客户端计算设备232不再链接到旅游管理系统230，客户接口应用程序266可以使用其它的通信方式如传真、电子邮件以及诸如此类。此外，提供商接口应用程序268从预订处理应用程序418获得通知，并将通知发送给相应的一个或一些提供商240。在本发明的一个实施例中，通知包括提供商240要求的数据，用来更新一个或多个的用户预订纪录。例如，通知可以包括用户姓名、信用信息、房间偏好、旅游服务确认号码、提供商确认号码和其它可以辅助提供商处理/确认预订的细节。通知信息还可以包括提供商240用来与旅游服务器确认调和账户(reconcile accounts)的不同的价格代码。
此外，提供商接口应用程序414也可以包括用来根据提供商规定的格式/通信媒介发送通知的通信组件。例如，提供商接口应用程序414可以从预订处理应用程序418接收标准编码的通知文件，如XML文件。与通信组件相结合，提供商接口应用程序414可以把标准通知文件转换成特别为提供商240而格式化的文件。例如，按照特定提供商240的规定，通知可以被格式化以便用传真来传送。或者，通知可以被格式化以使用提供商自己的电子接口(proprietary supplierelectronic interface)。一旦确认和/或通知已经被发送，子程序2000在方框2008终止。
参考附图19，在本发明的另一个实施例中，预订处理应用程序418可以与不直接连接到旅游管理系统230的一个或多个提供商240进行交互。根据本实施例，提供商接口应用程序268生成一个对于提供商240的通知，它通过各种通信媒介，如电话、传真、电子邮件、短信息服务以及诸如此类的任何一种来进行传送。不象前面的实施例(附图18)，在允许客户接口应用程序266向客户计算设备232发送确认信息之前，预订处理应用程序272等待接收来自于提供商的确认。本领域技术人员可以理解，附图19中显示的实施例允许旅游管理系统与可能具有有限的预订和计算资源的一个或多个提供商240进行交互。
在本发明的一个实施例中，旅游服务器236可以在数据存储器238或者其它存储地址中存储预订数据，取决于关系数据库数据存储格式。附图25是显示根据本发明，用于存储预订数据的关系数据管数据关系2500的框图。在本发明的一个实际的实施例中，数据关系2500可以被定制化，以包括对应于特定预订交易的独特方面的一个或多个数据表格或数据字段(例如，用来规定对租赁汽车的偏好的数据字段)。然而，本领域技术人员会理解，根据本发明，也可以使用其它的数据存储格式或者其它的关系数据库数据关系。
如附图25所示，数据关系2500定义了一个预订交易表格2502，可以操作来定义涉及预订交易纪录1702(附图17)的数据。在本发明的一个实施例中，预订交易表格2502可以包括预订交易数据2504，如预订ID字段、路线信息、销售点字段、旅行者用户ID字段、总结财务信息、生成日期字段以及诸如此类。此外，和关系数据库相一致，在预订交易表格2502中的一个或多个字段可以指向一个或多个附加数据表格，以进一步定义预订交易数据2504，如在2506显示的。
数据关系2500也定义了预订旅游者表格2508，可操作用来定义和请求预订的用户或者用户组相关的信息。在本发明的一个实际的实施例中，预订旅游者表格2508可以包括预订旅游者数据2510，如预订ID字段、姓名信息、地址信息、电话信息、电子邮件信息以及其它用户识别信息。
数据关系2500此外定义了预订项目表格2512，可操作用来包括对应于预订项目纪录1704(附图17)的预订数据。在本发明的一个实际的实施例中，预订项目表格2512可以包括预订项目数据2514，例如预订ID字段、确认信息、取消信息、消费者价格信息、提供商价格信息、提供商通知信息、改变和取消罚款信息、旅游者偏好和特殊要求信息，以及诸如此类。和预订交易表格2502相类似，预订项目数据2514中的一个或多个字段可以指向一个或多个附加表格，以进一步定义预订项目，如在2516中显示的。
继续参考附图25，数据关系2500定义了预订目录表格2518，可操作用来包括涉及预订目录1706纪录(附图17)的预订数据。在本发明的一个实施例中，预订目录表格2518可以包括预订目录数据2520，如预订项目ID字段、提供商价格信息、消费者价格信息、目录识别信息，以及诸如此类。此外，预订项目数据2518的一个或多个字段可以指向一个或多个附加数据表格，以进一步定义预订项目数据2520，如在2522中显示的。
在本发明的一个实施例中，数据关系2500也可以包括财务信息通用表格2524，它包括对于全部预订的所有消费者价格和提供商价格信息。例如，财务信息通用表格2524包括来自于预订交易1702纪录、预订项目1704纪录以及预订目录1706纪录的消费者价格和提供商价格信息。本领域技术人员会理解，财务信息通用表格2524协助生成对于所有预订的价格和成本信息。然而，根据本发明的一些实施例，财务信息通用表格2524可以被省略。
已经显示并描述了本发明的示范性实施例，可以理解，这其中可以做出各种改变而并不偏离本发明的精神和范围。