CN1774724A - 酒店管理系统和方法 - Google Patents

Abstract

本发明针对用于管理具有地理上分布的商业实体的酒店机构的方法和系统，各个所述商业实体提供了一个或多个相应的创收设施，比如旅馆房间、宴会设施等等。和商业实体所提供的设施的使用有关的安排通过多条渠道的一个或多个作出。在本发明一实施例中，一方法包括以下步骤：为商业实体维持一中央编目系统以及和商业实体相关联的相应设施；经由所述多条渠道的至少一个接收对和至少一个商业实体的至少一个设施相关联的报价；基于中央编目系统内的数据生成一报价并且响应于对报价的请求、经由所述多条渠道的至少一个发送所述报价。

Description

酒店管理系统和方法

本申请根据35 U.S.C.§119(e)要求2003年1月24日提交的临时专利申请第60/442198号的优先权，后者内容通过引用被完全结合于此。

技术领域

本发明一般涉及酒店管理，尤其涉及酒店管理系统和方法。

背景技术

酒店组织，尤其是那些具有许多地理上分布的商业实体和设施的组织，为使组织的利润最大，不断面临着这些企业设施的定价和预订的挑战。这样做又涉及到对作出价格查询、预约和预订的许多分布渠道、以及商业实体的分布式的不同特性、它们的管理和定价实行以及它们的信息系统进行结算。常规酒店组织的分布式、高度定制的的性质及其信息基础结构维护起来是昂贵的，难以和现有的或新兴的技术平台或解决方案集成和/或随之转移，并且要求在不同数据结构间昂贵的接口和转换，并且贮存每一个分布式商业实体的现有定制的解决方案。

与此同时，这些组织在能力上被限制访问或影响驻留在分布式商业实体本地的有价值的商业交易信息。这些限制源自于该组织的信息管理的分布式特性、提供信息访问所需的重大硬件投资、以及和在该组织的分布式商业实体和设置的用户界面之间出现的瓶颈相关的开销。随着酒店组织的扩张并且获得其它商业实体，趋于向原有系统(legacy system)打补丁的技术解决方案，增加了组织信息系统的复杂度和分离性。可从中收集信息的商业数据、以及和这些问题有关的决定(比如设施的定价)趋于保持本地化。

图1示出一常规酒店管理系统的典型结构示例，这是一般由具有多个地理上分布的商业实体的酒店组织所使用的类型。系统100包含一酒店组织的多个地理上分布的商业实体102，比如实体106、108、112和114，借此各个实体包括一本地储存库或数据库104。各个本地数据库104可以持有预订数据、有关顾客和团体的数据、以及和相应商业实体的日常运作有关的其它管理和市场数据。例如，商业实体106和108位于地理位置110，地理位置110可以是例如城市、地区、国家或甚至是一个洲。类似地，商业实体112和114位于不同的地理位置116。

如图1所示，各个商业实体102限于访问和它们的本地数据库104相关的本地数据，通常不能访问和其它商业实体或其它信源相关的数据。

商业实体106可能拥有和保存在其数据库104中的一个特定顾客或团体有关的重要数据。该顾客或团体日后可能决定在该酒店组织的另一商业实体(比如实体112)作出房间预约。商业实体112通常不能访问和来自商业实体106的顾客或团体有关的数据。实体106处的顾客信息可能表明该顾客(或团体)是具有特定优选项的经常顾客，这些特定优选项如果在预订过程中被考虑时，可能在实体112处设定一个优惠房价时被考虑。如上所述，实体112也许不能访问来自实体106的本地数据库的信息，或者由于能在预订设施时使用信息而这样做。此外，即使在实体106和112之间有通信基础结构，也不能保证数据在能被实体112所使用的足够短的时间内被访问。换言之，信息不是实时可用的。

如图1所示，系统互连框120在顾客122和商业实体102之间提供通信装置。顾客122可能是希望作出预约的个人124、公司126、团体128或是批发商130。每个顾客122都能通过各个分布渠道132开始预订过程，所述分布渠道比如未经预约134、通过全球分布系统(GDS)136、酒店组织的电话预约中心138、在线业务140(例如Travelocity^TM、Expedia^TM等)或其它渠道。

如果个人124希望作出预约或房价查询，他们可能通过多个渠道132这样做。例如，他们可能联系电话预约中心138来得到一特定日期的特定房间。从电话中心，有关于该个人和请求的数据通过通信信道142、接口(I5)144和接口(I2)146被发送到商业实体106，在那里基于接收到的数据以及数据库104中保存的其它所需信息数据来处理所述请求。在请求数据在实体106处被处理之前，定制的接口(I2)146可能需要转换或格式化请求数据(即来自电话中心的数据)，使得它与商业实体106处所结合的信息技术(IT)系统兼容。一旦请求已经在实体106被处理，就通过通信渠道142、接口(I2)146和接口(I5)144把房价数据发回预约中心138。有了请求数据，在电话预约中心138处更新房价数据之前，定制接口144必须把请求数据(即来自电话预约中心138的数据)转换或格式化成和电话预约中心138处运行的IT系统相兼容的格式。这一接口对于每个顾客122都是需要的，所述顾客通过分布渠道132之一和特定的一个商业实体102通信。

如图1所示，不同的分布渠道132和商业实体102一般需要通过定制的接口通信，比如接口144、146、148、150、152、154等。为了简洁，仅示出有限数量的商业实体、分布渠道和接口。对于有大量数目的商业实体的酒店组织来说，可能需要许多接口。同样，当已经通过例如GDS 136或电话预约中心(CRS)138作出了预订或预约查询时，这些系统(即GDS和CRS)的数据库(未示出)可能要求手动更新，而不是自动同步。

因而，商业实体间的信息共享和协调是次优的，且房间预约或其它设施的价格通常由各个实体的管理功能随意决定，而不是收益于任何一个能使用在酒店组织上收集到的情报的整体中央化协调的机制。酒店组织的商业实体上的这一数据，如果有，严重地限制了酒店组织的利润产生。

发明内容

至少部分通过根据本发明的系统和方法的各个方面，解决了上述的长期以来尚未解决的需求。按照本发明，酒店管理系统提供了一种中央式系统，该中央式系统用于存储、管理和处理与在一酒店组织的顾客、渠道和商业实体间出现的商业交易相关联的数据。访问这种中央式数据使酒店管理系统能最大化或提高其收入管理经验、提供灵活的装置以便把其它属性集成到该组织的管理系统基础结构中、并且能通过用于开始和关闭和商业实体间的商业交易的各个分布渠道上生成统一定价策略。

特别是，本发明的系统和方法包括一种用于管理具有地理上分布的商业实体的酒店组织的方法，所述商业实体提供一个或多个相应的设施，其中通过多条渠道的一个或多个作出和商业实体提供的设施的使用相关的安排。该方法包括以下步骤：为商业实体维持一中央编目系统以及和商业实体相关联的相应设施；经由所述多条渠道的至少一个接收对和至少一个商业实体的至少一个设施相关联的定价方案；响应于对和至少一个设施相关的定价方案的请求、基于中央编目系统内的数据生成一报价；并且响应于对所述定价方案的请求，经由所述多条渠道的至少一个发送所述报价。

本发明的另一方面包括一酒店管理系统，该系统用于提供和酒店组织的地理上分布的商业实体的设施相关联的定价方案，所述酒店管理系统包括：包括一数据存储系统的中央编目系统，所述数据存储系统用于保存和检取和任一商业实体的设施的预订相关的数据；以及一中央接口，该中央接口与中央编目系统和商业实体通信，并且可由顾客实体访问以用来预订至少一个商业实体的至少一个设施，所述中央编目系统适用于：基于数据存储系统中保存的以及和商业实体相关联的数据来生成报价。根据本发明一方面，定价方案可以是实时方案或报价。

本发明还有一方面包括一种运行一酒店组织的中央编目系统的方法，所述酒店组织具有多个地理上分布的商业实体。该方法包括以下步骤：维护和中央编目系统相关的数据库，所述数据库包括和多个商业实体的设施有关的中央生成的价格和可用性数据；接收对多个商业实体的至少一个设施的预订请求；基于所述预订请求，从数据库检取和该设施有关的数据；处理所检取的数据以便为该设施生成报价；响应于预订请求而发送所述报价；接收反映出报价接受情况的信号；以及基于反映报价接受情况的信号的接收而更新数据库。

同样，本发明另一方面包括一中央式系统，用于管理酒店组织的地理上分布的商业实体设施的定价和预订，所述中央式系统包括：一中央编目系统，用于维护和设施的定价和预订相关联的单个数据储存库；通过网络和中央编目系统通信的应用服务器，所述应用服务器可由中央编目系统通过网络访问以预订设施；以及和中央编目系统、应用服务器和至少一个外部系统通信的一中央接口，用于支持中央编目系统、应用服务器和至少一个外部系统间的通信。

同样，本发明再有一方面包括用于管理酒店组织的多个商业实体之一的方法。该方法包括以下步骤：通过网络从相对于多个商业实体为中央式的编目系统接收和商业实体设施的预订有关的数据；以及基于从中央式系统接收到的预订数据来分配商业实体的资源。

附图说明

图1说明了根据现有技术系统的酒店管理系统的概述。

图2说明了由本发明一方面的一实施例中的酒店组织所使用的酒店管理系统的概述。

图3说明了本发明一方面的一实施例中的酒店管理系统的系统结构。

图4说明了在本发明一方面的一实施例的酒店管理系统中、一中央编目系统与其它系统和实体的交互动作。

图5说明了在本发明一方面的一实施例中、酒店组织的销售代理和酒店管理系统之间的数据流。

图6说明了在本发明一方面的一实施例中、酒店管理系统的各个组件内的数据通信。

图7说明了由本发明一方面的一实施例中的酒店管理系统进行的信息处理。

图8A说明了在本发明一方面的一实施例中、和酒店管理系统相关联的方法流程图。

图8B说明了在本发明一实施例中、图8A所示方法的进一步步骤。

图9A说明了和本发明一方面的一实施例中的酒店管理系统相关联的方法的另一流程图。

图9B示出本发明一实施例中、图9A的方法的后续步骤。

图10A说明了和本发明一方面的一实施例中的酒店管理系统的预约和中央委托付款系统相关的方法流程图。

图10B示出本发明一实施例中、图10A的方法的后续步骤。

图10C示出本发明一实施例中、图10B的方法的进一步步骤。

图11示出在本发明一方面的一实施例中、用于通过电话预约中心对酒店组织的房间或其它设施作出预约的用户界面例子。

图12示出在本发明一方面的一实施例中、用于表示和通过电话预约中心作出的预约相关联的房价和可用性信息的用户界面例子。

图13示出在本发明一方面的一实施例中、在图12的用户界面内示出的房价细节用户界面。

图14示出在本发明一方面的一实施例中、和酒店组织的因特网主页相关联的用户界面例子。

图15示出根据本发明一方面的一实施例、由和酒店组织相关联的销售人员自动化(SFA)系统所使用的用户界面，其用于作出团体预约。

图16示出在本发明一方面的一实施例中、由收入管理员用来手工输入到酒店管理系统中所使用的用户界面。

具体实施方式

图2说明了在本发明一方面的一实施例中的酒店管理系统200的结构概述。该实施例中，但不加限制，酒店管理系统适用于管理一旅馆组织，但也可用于运行一航线，所述航线运作了多艘轮船、假期俱乐部、分时共管组织或任何其它酒店组织。如参照图1所述，系统200包括多个地理上分布的商业实体302，比如实体206、208、212、214、216和218。如上所讨论的，商业实体206和208位于特定的地理位置220，而商业实体210和212位于不同的地理位置222。商业实体210和212可能是例如在不同的地区、州、国家或洲。

商业实体202的数目可很大地变化。图2所示的几个商业实体(例如206、208、210、212、214和216)是为说明起见而不是为了限制。

所有和商业实体以及他们提供的设施、愉悦度和服务有关的数据都驻留在一中央编目系统224上。根据本发明一方面，和酒店组织的商业实体202之间的交易，比如旅馆房间预约，可以通过中央编目系统224来实施。

中央编目系统224包括一中央储存库226，其用于保存和旅馆可用性、房价(或报价)以及预订(即预约)相关的数据，借此储存库可以包括任一用于存储和检取数据的系统，包括但不限于一数据库。它还包括一分配逻辑模块228，其使用酒店组织的收入管理商业规则来计算和优化通过各个分布渠道接收到的预约的报价。分配逻辑模块228包括和中央储存库226相关的软件。设施的房价基于收入管理规则生成，比如逗留模式(stay pattern)、卖空限制和房价阻碍(rate hurdles)。因此，房价和可用性的产生全都在中央编目系统224内处理，而不会有通过个别商业实体及其相应的本地数据库和不同的预订请求或预约请求相接口的负担，所述商业实体比如图1所示的实体106、108、112或114。

各个分布渠道230包括但不限于：不经预约232、全球分布系统234、电话预约系统236、组织销售人员238、因特网主页240、在线业务242以及其它业务244，每个渠道都向顾客246提供了通过中央接口250对酒店管理系统200的中央编目系统224的访问。顾客246，比如个人252、公司254、团体256或批发商258，分别能通过分布渠道230之一请求预约或预订。也可以向现有的渠道230动态添加其它分布渠道(未示出)。顾客246和渠道230可以总体上被视为顾客实体，它们是以自己的名义或者联合它们的布局而运作或服务的顾客，包括旅行代理、酒店组织的销售人员、商业实体的销售代表等。

收入管理引擎262可以是一收益管理工具，它可以被调用以便基于储存库226中保存的逗留模式和历史预订数据来提高收入情况。保存在储存库226和收入管理引擎的储存库(未示出)中的所有历史数据都被更新，最好是在它被创建时(例如通过预订数据)实时更新，使收入管理引擎262能基于中央式的、最近且有效维护的数据储存库226使收入最大化。作为收入管理引擎262的一部分被使用的收益管理工具可以是由Micros-Fidelio公司授权的TopLine PROFIT^TM(TLP)企业中央收益管理系统，该公司总部设于San Jose，加利福尼亚，或者可以是其它适当的工具。

收入管理引擎在商业实体202的占有率高时最有效。在这些情况下，使用收入管理引擎262预报当场的将来需求使商业实体202能限制其房间和设施(例如会议资源)的一个特定部分或百分比，留给当场销售(即不经预订的销售)。因此，通过考虑到和其它利润较小的渠道(例如GDS)相比的当场预订，可以提高收入，在本发明一实施例中但不加限制，和传统的酒店管理系统相比高达5％。传统的酒店管理系统一般可以不包括收益管理商业规则，并且可以为各个分布渠道使用分开的储存库。

中央接口250使用一公布/预订通信系统在中央编目系统224和酒店管理系统的几个组件之间提供了中间件接口，所述组件比如商业实体202、分布渠道230和收入管理引擎262。系统200的其它组件(见图3)也通过中央接口250和中央编目系统224相接。中央接口250包括在酒店管理系统200的各个组件(例如中央编目系统)之间提供公布/预订通信的多个接口模块266。如图所示，每个分布渠道230用一相应的模块266和中央编目系统相接。类似地，商业实体202也用模块266分别和中央编目系统相接。同样，收入管理引擎262和数据仓库组件268经由模块266的公布/预订通信系统与中央编目系统224的分配逻辑模块228进行通信。公布/预订通信是异步的多播通信，并且能快速适应于动态变化的环境。多播传送方面使公布者能够仅用一个公布操作向许多订户发送同一事件。中央接口250中间设备层可以用BEA Systems公司的产品Tuxedo^TM或者其它适当的工具来实现，BEASystems公司位于San Jose，加利福尼亚。

公布/预订通信结构的动态且可高度缩放的特性为酒店管理系统200提供了一种灵活且自适应的技术基础架构，便于系统200内其它分布渠道230和商业实体的集成。虽然当前的公布/预订模型为系统200不同组件间的数据流的接口和管理提供了一种解决方案，然而系统200内也可以结合其它数据通信和接口结构，而不背离本发明的精神和范围，这和对于现有技术系统的各个组件使用不同过程(数据格式、协议等)的常规方法相反，所述常规方法有最小的灵活性和可缩放性。

数据仓库268包括一数据库或储存库，用于基于从顾客的先前预订历史提取的数据，存储和顾客的要求和/或优选项有关的数据。例如，如果诸如团体256或个人252这样的顾客以前已作出了预订，中央储存库226就已保存了和该特定顾客(即个人或团体)的具体优选项和要求有关的数据。优选项信息可以是例如：所选的报纸、房间特征(例如大尺寸床、吸烟、海景)、健身设施、高尔夫球场等等。逻辑控制模块228经由中央接口250内的接口模块266之一把数据从储存库226发送到数据仓库268，数据被保存在数据仓库268供企业智能模块270的进一步处理。

企业智能模块270处理和各个交易相关的数据，所述数据可能包括渠道230或顾客信息，以便从数据仓库268中保存的信息中提取优选项/要求。一旦优选项/要求数据被模块270提取，它就被酒店组织的市场、销售或运营商业功能内的用户所访问，以便提高市场利润并且提高客户满意度。或者，优选项/要求数据可以被保存在数据仓库268中，在那里它在处理顾客请求期间被逻辑控制模块228访问。酒店管理系统200的各个子系统，也就是中央编目系统224、中央接口250、收入管理引擎264、数据仓库268、企业智能模块270和商业实体220、222，所进行的数据处理是实时的。该实时是从以下意义上说的：一旦信息或状态信息变化或者变得可用，并且受到计算机系统和网络的普通处理和传输等待延时，信息和状态信息就被立即更新并且被适当地保存在系统的不同部分。这对于中央编目系统224尤其如此。实际上，不存在可能对商业决定作出重要影响的相关延迟。

图3说明了按照本发明一方面的一实施例的、酒店管理系统的总技术结构300的实施例。技术结构包括在服务器302上运行的多层(multi-tier)分层方法，所述服务器302例如J2EE应用服务器或其它适当的服务器。第一层是web服务器304，它包括超文本标记语言306、Java服务器页面^TM(JSP)308、Servlets^TM310和web服务312 J2EE组件。对于那些组件的每一个，也可以使用其它适当的技术。第一结构层内结合的其它标准Web逻辑工具314是：协作316、工作流程318、个性化320以及商务服务器工具322。例如，商务服务器工具322用于开发在线存储设施，而个性化工具用于web安全开发目的。

结构中的第二层是容器324(例如Enterprise Java Beans^TM(EJB)容器)，其包括配置和可用性326、预约328以及销售人员自动化(SFA)330组件。根据已知方法实现的这些组件形成了应用在结构的应用层的基本商业规则逻辑。例如，向通过应用程序接口(API)(见屏幕快照附图)输入的预约信息所应用的相关商业规则由预约组件328处理。类似地，由酒店组织的销售团队通过API输入的信息由SFA 330组件或模块处理。组件332说明可以添加更多的组件(例如EJB或其它适当技术)以便扩展系统的商业规则功能。

第三层包括数据库服务器324，它可以是Oracle数据库或者使用其它适当的可用技术。数据库服务器324包括储存库数据库336，它是中央编目系统226的存储和数据管理设施。数据库服务器334还包括数据库338，它是参照图2描述的数据仓库。结构中的第三层还包括一XML通信模块340，用于在应用服务器302、数据库服务器334和企业应用342之间提供通信装置。如上所述，接口由中央接口334的中间件结构所提供。应该理解，所示的结构不限于目前结合的技术，而是可以包括例如在一通信网络上运行的其它应用接口。同样，通信装置的规模可以是本地的、大城市规模、或全球规模，并且使用基于无线的(例如微波、卫星等)或波导的(例如同轴电缆、光纤等)通信介质。此外，用于信息交换的协议也可以根据组织的大小和商业需求而变化。

企业应用342经由中央接口344和多层酒店管理系统通信，企业应用342包括财产管理系统(PMS)344、收入管理引擎(TLP)346、企业资源规划348、客人历史管理350以及忠诚奖励和激励352模块。每个财产管理系统342都负责管理和一商业实体的设施(比如旅馆)的预约、常规事务、人力资源、采购、管理、会计和设施有关的数据。所述设施可以包括咖啡厅、餐厅、礼品商店、酒吧、高尔夫球场、健身中心、宴会厅和会议室，或者可供商业实体产生收入的其它资源。一旦顾客确认了一预订或预约，和预订有关的信息就由储存库数据库336通过XML通信模块340和中央接口344发送到财产管理系统344。然后，用顾客的特定房间预约来更新旅馆的财产管理系统324。类似地，当顾客付账后离开或者没有登记入住时，这种更新后的状态信息通过接口344和XML通信340被发回储存库336。因此，中央编目系统的储存库336被实时地更新，借此由于后续预订被阻止的房间被释放，并且在储存库336中可用。

收入管理引擎346通过XML模块340和中央接口344从储存库336接收数据，以便提供收益管理计算。一旦预订房价和收益管理数据被收入管理引擎346所处理，数据就通过XML模块340和接口344被发回储存库336，在那里实时地更新信息。企业资源规划(ERP)模块348也由从中央编目系统的储存库336发送的信息所更新。ERP 348是酒店组织的管理系统，包括例如人力资源信息、财务信息和供应链信息。

客人历史和活动跟踪模块350保留和以下有关的信息：客人优选项、顾客终身产出(lifetime production)、促进的生产力(promotional productivity)、以及对关于酒店系统活动的市场营销的定量度量。该模块也通过通信模块340和中央接口344由中央编目系统所更新。忠诚奖励和激励模块352记录组织的各种奖励方案、佣金和激励方案，鼓励个人和/或组织相对于另一酒店组织而预订和预约该酒店组织。例如，个人可以登记或订购各个预约或预订的接收点，会授予他们仅对这种已预订的顾客可用的将来的促销、特别优惠或者折扣。其它激励措施可以包括这样的方案，该方案对于代表其公司团体或上司预订或预约房价和/或设施的公司助理是可用的。

外部应用354包括全球分布(GDS)系统356，如图2所述，系统356通过把各个旅行代理或第三方的查询发送到中央编目系统以进行处理，从而提供了使各个旅行代理或第三方能代表顾客访问并作出实时查询、预订和预约的分布渠道。如图所示，这些GDS 356也通过XML通信模块340和中央接口344和储存库336通信。

组织的互联网客户机360包括旅馆362、联系人中心364、地区办公室366以及公司办公室368，它们通过组织的局域网和/或广域网资源370和酒店管理系统200的应用服务器302进行通信。例如，组织的销售人员可能访问应用服务器302和相关的网页以便通过互联网客户机360为团体顾客作出预订。类似地，外部互联网客户机372包括商业到商业的客户机376(B2B)以及商业到顾客的客户机374(B2C)，这些客户机能通过因特网378、并经由酒店组织的防火墙380来访问酒店组织的应用服务器302。无线应用协议(WAP)工具382也可用来向因特网和应用服务器302提供无线访问。

在本发明一方面的一实施例中，图4示出中央编目系统400和其它实体间的互相动作的概念图示，所述其它实体在酒店管理系统内以及在酒店管理系统外部。中央编目系统和语音预约中心402、财产管理系统404、外联网406、收入管理引擎408、基于因特网的客户机410、以及销售支持或销售人员自动化(SFA)系统412进行双向通信。语音预约中心402向顾客提供了拨打中心免费号码以作出预约查询和预订的机会。中央编目系统400提出房价并将其传回语音预约中心402。对组织内所有商业实体的所有预订都是通过中央编目系统400确立的。

和相应的商业实体相关联的财产管理系统(PMS)404传送与房价和设施相关的状态信息，并且不基于顾客查询而设置房价或定价方案。中央管理系统400通知PMS 404有关已经由顾客作出的任何预订(即确认的预订)的特定商业实体。PMS404又通知中央编目系统400有关状态更新，所述状态更新和被空出或可供新商业使用的(例如已结账离开)的已预订设施或房间有关。为客户机开发了外联网406，被赋予对组织的应用服务器302(图3)内的特定应用接口有特别的访问。例如，酒店组织会创建一特定的因特网网页，该网页为一公司的雇员提供了独占预订。该公司具有访问外联网406的密码，对房间和/或设施的预订价格根据以前在酒店管理系统和公司间协商好的合同条款和条件来计算。

收入管理引擎408从中央编目系统400接收数据，并且计算价格并应用编目限制，以便使收入最大化。一旦收入管理引擎408已经计算了一价格方案，和所生成的价格方案相关的数据就被发送到中央编目系统400，它在那里把价格方案分布到所需的渠道，比如语音预约中心402或外联网406客户机。中央编目系统400也对基于因特网的客户机410的预约和预订进行集中处理。基于因特网的客户机410可以包括通过酒店组织的主页来访问酒店组织的预约和预订网页(或其它用户界面)的顾客。顾客对一特定预订的方案请求(即预订或预约报价)被发送到中央编目系统400，在那里被处理。然后从中央编目系统400把所计算的价格发回顾客。其它基于因特网的客户机可以是在线业务，其使用B2B因特网访问来向顾客提供来自中央编目系统400的价格方案。

酒店组织的销售人员系统412通过因特网从旅馆362(图3)和公司办公室368(图3)提供分布式的销售运作，提供了实时的房间可用性。对于其它系统，销售人员自动化系统412把价格或定价查询发送到中央编目系统400，中央编目系统400又生成通过销售人员自动化系统412被发回相关代理的价格或定价方案。销售人员自动化系统412包括一销售人员自动化组件330(图3)，组件330通过账户为个人顾客、团体(例如旅行团)以及事件(例如会议)提供公司协商和跟踪。例如，销售人员自动化(SFA)组件330(图3)可以向一代理提供电子邮件提醒，以便跟随前面和一特定团体协商的合同。如果一些房间仅为了这一团体暂时预订而未最终确定，则这些房间可以被中央编目系统所释放。该提醒使代理能跟随该团体，以确保他们临时请求的房间尚未丢失。该提醒还能在发现该团体不再希望确认预订后把房间和资源释放回编目系统。通过使用系统的SFA组件330(图3)，代理能处理对多个商业实体的预订，而无须在每个商业实体处和一管理者协商。中央编目系统400提供了一个所提议的价格，该价格在所有其它分布渠道(即销售)上都是统一的，并且向顾客提供了和所提议定价的“公正性”有关的较高置信度。

销售人员自动化模块330(图3)由用于处理和管理团体的预约或预订步骤的基本商业规则组成。这种商业规则的例子可以包括：跟踪(follow-up)日期、基于一给定价格对一特定预订的可选日期、付押金的截止日期、多个商业实体查询能力、基于逗留时间长短的价格等等。销售人员自动化模块330(图3)使用收入管理引擎来生成实时的推荐，所述实时的推荐用于确定酒店组织销售代理在生成一方案时所能报出的价格。这一价格包括“最低(loose-it)”推荐，该推荐是基于团体对房间或设施的请求所能提供给该团体的最低价格。例如，如果以每晚100美金的价格请求了100间房间，收入管理引擎可以预报这些房间不能以这些价格售出，因为现订旅客的预期季节性增长会为这些房间付高得多的价格，从而使收入最大化。

如果在收入管理引擎的计算后，一团体对一特定价格的请求被拒绝，那么销售代理可以联系一收入管理者或收入管理团队，这个人或团队负责监视酒店组织内的收入管理。收入管理者有权利不考虑作为中央编目系统的潜在预订处理的一部分而生成的收入管理引擎推荐。

销售人员自动化模块330(图3)管理团体的预期的预订或定价期望(即“先导(leads)”)，并且向销售代理提供支配团体留在旅馆或特定商业实体处的各种规则和策略。例如，一些大公司希望在酒店组织的特定商业实体处召开会议或贸易展览，所述大公司可能请求提供非酒精饮料。或者，他们可能请求(在合同中)为其公司的执行官提供特定大小的房间。这些及其它类似信息由销售人员自动化模块330(图3)处理，用于帮助酒店组织的销售代理有效地管理团体预订或预约。

在本发明一方面的一实施例中，图5说明了对于个人和团体的预订和预约来说、在酒店组织的销售代理或执行官以及酒店管理系统500之间的数据流。销售代理通过符合商业规则504的web把和一团体预订有关的预期查询502(即先导)发送到酒店系统500。“先导”的商业规则504可以包括执行逗留时间、可选的日期等。和一“先导”相关的数据被发送到中央编目系统506以进行处理，收入管理系统508从编目系统506接收该数据，并且执行一组分析。一旦分析完成，中央编目系统506就根据商业规则504把和先导相关联的方案510发送到销售代理。例如，根据商业规则504，可以为响应于方案510而设置一截止日期。如果在该日期前系统未接收到应当的付款，则释放在“先导”内执行的所请求的资源，这些资源可供其它团体或渠道使用。和销售代理相反，销售实体可以是销售人员、像酒店财产等商业实体的职员、旅行代理、活动策划者等等。

收入管理引擎508响应于对从销售人员接收到的先导的处理，生成一变量度量，称为“预订点”。根据一团体接收到的预订点，收入管理者可以拒绝或接受一团体的预订。例如，如果两个团体对一特定商业实体内的资源进行竞争，收入管理者就可以使用预订点作为确定要拒绝哪个团体的手段。然而可以理解，收入管理者在本发明一方面的实施例中拥有不考虑收入管理引擎508的权利，如果确定具有较低预订点的团体是潜在的将来的重要顾客，收入管理者具有拒绝有较高预订点的团体的判断力。

应用于酒店管理系统500的商业规则504在几个节点上运行，比如可能形成一J2EE集群的节点512和514。如图所示，两个节点512、514都支持中央编目系统506的运作。节点512、514优化数据库访问并且提供增加了的冗余，用于管理销售渠道和中央编目系统506之间的实时数据交易。

图6说明了一简化图，示出酒店管理系统600的各个组件间的基本数据通信。顾客602通过在通信信道604上联系一销售执行者或代理606(可称为“先导”)来请求一报价(例如预订、价格方案等)。可以理解，顾客可以使用任何其它可用的渠道以及销售代理来请求报价。通信链路604可以是、但不限于：电子邮件、因特网、传真或其它通信手段。销售代理606基于顾客请求以及对商业实体608之一处的特定团体预订的优选项而生成一“先导”。该先导经由通信链路610被发送到中央酒店管理系统612。中央酒店管理系统612包括图3所述的应用服务器、EJB容器和数据库服务器的多层结构。在当前实施例中，通信链路610是因特网，然而，通信链路可以包括销售代理606和中央酒店管理系统612之间的任何兼容的通信解决方案。如果先导在收入管理引擎(未示出)的实时处理和分析后被中央酒店管理系统612所接受，则通过链路610把一方案发回销售代理606。如果顾客602也接受该方案，就在所选的商业实体608之一处保留所需的设施，比如商业实体616。因而，中央酒店管理系统612把预订或预约信息发送到商业实体的财产管理系统618(PMS)。

如果先导未被中央酒店管理系统612所接受，销售代理606就可以联系收入管理员620并且建议根据和请求预订的团体(例如潜在的将来的大客户、或将来的商业伙伴等)相关联的环境来接受该先导。如果代理606的方案被接受，收入管理员620(可以是一个人)可以手工地忽视中央酒店管理系统612对团体先导的拒绝，并把预订输入到系统内。所有与预订和资源分配相关的信息都由中央酒店管理系统612分布到其它系统组件用于更新622(例如ERP的更新、基于预订获得忠诚奖励的更新)。

在图2到7中，尽管可以为说明起见在各个图中用不同的参考数字来标识特定的实体，然而它们可能对应于本发明实施例中的同一实体。

图7说明了根据本发明一方面的一实施例、由酒店管理系统在为商业实体内的各个设施处理顾客查询并生成定价方案时所使用的信息处理。酒店管理系统处理和酒店工业相关联的各个参数。根据本发明的该实施例，这些过程被归类为市场分析702、策略定义704、需求预报706、优化战略708、房间预约710以及监视712。每个类别都包括根据箭头注意或执行的多个阶段或步骤。下面讨论这些步骤的顺序，该顺序可以变化而不背离本发明。

市场分析702包括信息评估，比如信息收集714、竞争/本地分析716、顾客分析718、定价和弹性分析720、分布渠道分析722、旅馆结果分析724以及市场分割726。

策略定义704类别包括注意价格策略728、渠道/分割策略730、通信策略732、收入管理策略734以及激励策略736。

需求预报类别706包括：集成历史数据库738、标识季节定义740、标识不寻常事件742、需求和卖空预报744以及偏离监视746。

优化战略708包括分析需求预报748、分析预订750、季节结果比较752、分析价格涨跌(wash and stay)模式754、分析竞争者策略756、定义卖空限制758、定义每个逗留模式的预约数760、以及定义最低价762。

房间预约类别710包括顾客分割764、理解顾客要求766、实施要求评估768、协商利益770、协商提升销售(up-sell)772、停止交易774、预订预约776以及实施后续步骤778。

监视类别712包括定义度量780、定义目标和责任782、实施性能监视784和偏差分析786、以及定义行动计划788。

信息收集714、竞争/本地分析716、顾客分析718、定价和弹性分析720、价格策略728以及通信策略732是作为酒店组织的销售方法的一部分执行的过程。集成历史数据库738、标识季节定义740、标识不寻常事件742、需求和卖空预报744、偏离监视746、分析需求预报748、分析预订750、季节结果比较752、分析价格涨跌模式754、定义卖空限制758、定义每个逗留模式的预约数760、以及定义最低价762是由酒店组织的收入管理过程(即图2所示的收入管理引擎262)所执行的过程。分析预订750、实施季节结果比较752、分析价格涨跌模式754、执行顾客分割764、理解顾客要求766、实施要求评估768、协商利益770、协商提升销售(up-sell)772、预订预约776、实施后续步骤778、性能监视784以及实施偏差分析786是由中央编目系统224(图2)执行的过程。

分布渠道分析722、旅馆结果分析724、市场分割726、渠道/分割策略730、收入管理策略734、激励策略736、分析竞争者策略756、停止交易774、定义度量780、定义目标和责任782以及定义行动计划788是可以手工执行的过程。

图8A说明了和本发明一方面的一实施例中的酒店管理系统相关联的商业过程的流程图。商业过程步骤在顾客802、销售执行者或代理804以及收入管理者806间进行。在图8A和8B的描述上下文中执行的收入管理者既可以对应于作为个人的收入管理者，也可以对应于一收入管理引擎，该引擎通过处理和顾客请求相关的数据来进行收入管理。

在步骤808，顾客对方案或报价作出请求，所述方案或报价可以包括和所需的设施相关的信息，所需设施例如房间数目、逗留时间以及符合要求的会议室等。在步骤810，顾客生成的对方案或报价的请求由销售代理进行分析。配置价格和团体策略信息812也由销售代理访问，以便在步骤810分析对方案的请求。在方案分析之后，在步骤814，生成对方案请求的查询。在步骤816、818和820，处理所生成的查询，以便确定房间可用性、会议室可用性以及/或者设施的可用性。如果在步骤822确定满足了对方案查询请求的要求，则在步骤824，获取和接收到的方案请求相关的收入管理信息以进行分析。收入管理者可以访问和来自中央编目系统的方案相关联的价格设置数据。在步骤826，实现收入管理评估分析(即收入管理引擎)，并且在步骤828，解释这一分析的结果。基于在步骤828实现的所解释的收入管理评估分析的结果，或拒绝或接受该方案。

如果方案请求被拒绝，则在步骤830，收入管理者生成顾客请求的可选方案。在步骤832，确定顾客请求被拒绝，基于收入管理者所生成的可选方案，在步骤834把对方案的经修改的请求发回顾客供考虑。

如果方案请求在步骤826和828之后被接受，则基于最终确定预订或预约的较低期望(weak tentative prospect)838，在步骤840和842，基于顾客请求生产一方案和合同。

或者，当方案请求被拒绝时，在步骤836，销售代理可以联系收入管理者并且请求接受该方案。如果收入管理者决定有接受方案的范围(例如公司这样的潜在的重要顾客)，则不考虑评估分析及其解释(由收入管理引擎在步骤826和828生成)。基于最终确定的预订的较低期望838，如步骤840和842所示，基于顾客请求生成方案和合同。

如果在步骤822确定未满足要求(例如没有房间可用)，则在步骤834，修改对方案的请求并在步骤808发回顾客。如果在步骤828顾客接受了经修改的方案，则方案会被重发到销售代理以供在步骤810分析。如果请求不能完成且顾客对继续对方案提出新请求没有兴趣，则在步骤826，终止对方案的请求。

一旦已经分别在步骤840和842生成了方案和合同，则在步骤844就把方案发送到顾客供审阅。图8A所示方法的后续步骤在图8B示出。如图8B所示，一旦顾客接收到方案，在步骤846，他们就可以拒绝、接受或重新协商方案的条款(例如房价)。同样，在把方案发送到顾客的同时，如步骤844所示，销售代理被授权对所请求的房间作出及早的有条件的封锁，如步骤850所示。如果接受了所准备的方案，在步骤852，顾客就有签署合同的选项。这表明最终确定预订的较高期望，如步骤854所示。如果顾客签署了合同，在步骤856，销售代理就封锁在所生成的方案中指定的房间和资源。然而，在步骤846，顾客可以拒绝在步骤844(图8A)为顾客审阅而发送的所生成的方案。该情况下，预订过程终止，如848所示。或者，在步骤853，顾客可能决定重新协商方案的条款。在步骤834(图8A)，顾客对方案的请求被修改，并由销售代理重新提交供重新评估(即步骤808、810、816、818、820、824、826、828)。而且，在步骤852，顾客可能不签署合同，但可能决定重新协商所生成方案的条款，如步骤854所示。

一旦签署了合同，在所生成的方案或报价中指定的房间和资源(即设施)就被封锁，如步骤856所示。在步骤858和860，一旦支付了押金并且向销售代理发送押金通知，在步骤862，就必须确认该押金。在步骤864，检验接收押金付款的最后期限。如果这一期限已到期，则在步骤866所示，被封锁的房间和资源被释放，如步骤868所示。如果确认了押金，就确认了团体预订，如步骤870所示。这表明预订状态是不可更改的，如步骤871所示。因此，房间或资源(即设施)完全被分配给顾客。在步骤872，作为步骤870的确认结果而生成一房间列表(即占用房间的人的列表)。一旦生成了房间列表，该列表就在步骤874被处理。在步骤875，一旦建立了顾客或团体的离开时间，在步骤878，实际确认结果(即所生成的实际收入)就和收入管理者的分析相比较。在步骤880，评估这一比较结果供将来的收入管理计划和考虑。在步骤881，评估状态被确定为是完整的。

图9A说明了和本发明一方面的一实施例中的酒店管理系统相关联的方法的可选流程图，其中与图8A和8B相关的过程步骤参照顾客、销售代理以及酒店管理系统的不同组件而被指示。

顾客902从销售代理906作出对价格方案904的请求。销售代理906分析对方案的请求908。然后，销售代理906基于对方案的请求创建一group master 910(查询)，该查询被发送到销售人员自动化模块912(图3)。会议室可用性914在销售人员自动化模块912处由销售代理906确定。同样，销售代理906通过访问中央编目系统942来确定房间可用性916。一旦在中央编目系统942确定了可用性，销售代理906就向收入管理者920请求收入管理分析918。如果不需要和收入管理者920协商，就用收入管理引擎922对和价格方案请求相关联的查询进行收入管理分析和处理924。

收入管理引擎922所进行的分析结果以及对查询926提出的可选方案由收入管理者920发送到销售代理906，在那里生成一方案合同。在这一阶段也会发生预备房间(或其它设施)的封锁。然后把方案合同发送给顾客902供顾客查阅和签署930。方案合同包含和顾客902对价格方案的请求相关联的报价。一旦合同已签署，销售代理906就向销售人员自动化模块912登记该合同932。在登记合同932后，和要被封锁的团体、价格和房间有关的信息934由销售代理906创建、并发送到销售人员自动化模块912。销售人员自动化模块912调用中央接口938内的公布/预订通信系统936(即调用“NewGroup”服务)，以便把团体数据发送到收入管理引擎922、中央编目系统942和财产管理系统919，使得包括被封锁房间940的合同信息被更新。然后把和封锁会议室944相关的信息从销售代理906发送到销售支持系统912。

图9B示出在图9A中示出的企业过程的后续步骤。如图9B所示，一旦顾客902查阅并签署了合同946，它就被销售代理906所接收。可能需要像押金这样的有效保证。然而，这一要求可能对重要的客户被忽视。然后，销售代理906对销售人员自动化模块912、PMS 919和收入管理者920确认团体预订948(即确定性的)。收入管理者920还向收入管理引擎922确认团体预订948。顾客902把一任选的房间列表950发送到销售代理906，借此销售代理又发送房间列表供PMS 919处的处理952。一旦已经向PMS 919中输入团体已付账后离开954(即离开)，PMS 919就在中央接口938处调用一“ChangeStatus”服务956。然后，中央接口938把和所释放的房间有关的状态和信息的变化发送到中央编目系统942。

收入管理者920从PMS 919得到实际团体性能，并且把团体性能和收入管理分析962相比较(即评估)，所述分析962由收入管理引擎922执行。这提供了和收入管理引擎所实现的收入预报相关联的准确性度量。

图10A说明了和本发明一方面的一实施例中的酒店管理系统的预约和中央委托付款系统相关联的方法流程图。如图所示，过程步骤示出中央编目系统1002、中央接口1004以及旅馆1006这样的商业实体之间的互相动作。在步骤1008，中央编目系统1002输入一预订或预约，附有可用的委托规则。委托规则取决于在建立预订时使用的分布渠道。例如，向GDS、国际财团或在线业务支付的委托数量会在其间改变。在步骤1010，中央编目系统1002把预约消息发送到中央编目1004。在步骤1012，中央接口1004接收中央编目系统的预约消息，并将这一消息转换成一格式，该格式允许旅馆的财产管理系统(PMS)接收和处理该消息，如步骤1014所示。在步骤1016，中央接口1004把预约消息传送到旅馆的PMS。基于接收到的预约消息，在步骤1020，作出对房间的预订或预约。在这一预订后，在步骤1022，把登记入住的信息输入到旅馆PMS中。一旦登记入住完成，在步骤1024，中央接口1004就从旅馆1006接收登记入住消息。在步骤1026，处理登记入住消息并将其发送到中央编目系统1002，在步骤1028，输入登记入住快照(即在登记入住时预约数据的副本)。基于接收到的登记入住消息(步骤1026)，在步骤1030，在中央编目系统1002中更新预约状态和数量。在旅馆1006，在步骤1032，所有和顾客逗留相关的费用都登记在旅馆的PMS中。在步骤1034，付账后离开的过程完成，并且把和付账后离开过程相关的消息发送到中央接口1004，如步骤1036所示。在步骤1038和1040，付账后离开消息被中央接口所接收和处理。在步骤1030，基于接收到的付账后离开消息(步骤1040)，在中央编目系统1002中更新预约状态和数量。然而，这一情况下，在中央编目系统1002中更新付账后离开状态。在步骤1042，把一付账后离开快照输入系统1002。

在中央委托付款系统1004，在步骤1046，把预订和付账后离开快照导入中央委托付款系统的数据库。

图10B示出图10A所示方法的后续步骤。如图10B所示，在步骤1048，把更新后的委托状态(即已发送的)发送到中央编目系统1002用于更新委托状态，如步骤1060和1062所示(见图10C)。在步骤1050，比较预订和付账后离开快照，以便标识出任何差异。在步骤1052，基于所标识的差异，应用付款和生产力规则。如果在这一过程期间出现任何例外(例如错误、欺骗、付款数量不一致等)，在步骤1054，就向管理员发送一通知。在应用了付款和生产力规则后(步骤1052)，在步骤1056，把委托和超越委托交易集成到中央委托付款系统的数据库中。在步骤1058，这一更新后的委托信息被发送到中央编目系统1002用于更新委托状态，如步骤1060和1062所示(见图10C)。步骤1058处更新后的状态可以是“不可委托”、“未应用”或“在进程中”。在步骤1068，计算可付款的委托数量。

图10C示出图10B所示方法的后续步骤。如图10C所示，一旦调节在数据库中更新，如步骤1066(见图10B)所示，在步骤1070，就把更新后的委托信息发送到中央编目系统1002用于更新委托状态，如步骤1060和1062所示。一旦在步骤1068计算了可付款的委托(图10B)，付款就或者被推断，由此推断的状态在步骤1080被更新，并且被发送到中央编目系统1002用于更新委托状态，如步骤1060和1062所示。或者，如果付款未被推断，在步骤1072，就生成付款指令。基于步骤1072所示的所生成的付款指令，付款指令被发送到企业资源规划(ERP)系统1065，如步骤1074所示。在步骤1076和1078，付款指令被ERP系统1065接收和处理。在步骤1080，把和委托付款相关联的成功的和失败的交易信息发送到中央委托付款系统1044，它在系统1044处在步骤1082被接收。在步骤1072后，基于所生成的付款指令，在步骤1084，把更新后的委托状态发送到中央编目系统1002，如步骤1060和1062所示。同样在步骤1072后，在步骤1086，生成收支平衡报表。

在步骤1088，从步骤1082接收到的成功的和失败的交易信息被发送到中央委托付款系统1044，在那里接收和更新委托状态(即已付款或被拒绝)，如步骤1060和1062所示。在步骤1082后，如果付款交易成功，则在步骤1090，在中央委托付款系统1044处登记一付款确认标识(ID)。同样，在步骤1092，在中央委托付款系统的数据库中更新委托和生产力交易状态信息。

图11示出根据本发明一方面的用户界面(这里是一网页屏幕快照)1102的实施例，该用户界面1102用于输入和通过电话中心(图2的电话中心236)作出的预约相关联的逗留信息。如图所示，数据输入屏幕包括逗留信息部分1104、相关档案部分1106和联系人信息部分1108。逗留信息部分1104包括多个数据输入字段，所述字段用于输入旅馆代码1110、到达数据1112、离开日期1114、旅行原因1116以及逗留夜晚数1118。

相关简档部分1106包括多个数据输入字段，表示IATA代码1120、企业源(SOB)代码1122、促销代码1124、常客代码1126以及合同代码1128。通过IATA代码1120，酒店管理系统管理和处理对旅行代理的各种委托付款。基于SOB代码1122、促销代码1124和常客代码1126，向顾客报出一特别价格。如果没有合同，则不填写合同代码1128字段。如果输入一合同代码，则向顾客报出的预订价格就会取决于可能已经在例如销售代理、收入管理者(人)和顾客之间发生的预先协商。

合同信息部分1108包括多个数据输入字段，用于输入PIF代码1130、名字1132、姓氏1134、电话号码1136、C2K代码1138以及电子邮件地址1140。PIF代码用于把忠诚点分配给直接通过酒店组织的网站或中央预约系统进行预订的各个销售代理。类似地，C2K代码1138是另一忠诚点系统，用于激励公司的个人助理(PA)用酒店组织的直接预订渠道为其同事和经理作出预订，比如酒店组织的网站或中央预约系统。在屏幕1102上输入的信息可以被保存1142或被清除1144。或者，用户可以通过激活“取消”1146来退出屏幕1102。

图12示出根据本发明一方面的一实施例的网页屏幕快照1202的说明性例子，该屏幕快照1202用于指示和前面屏幕中输入的数据相关联的可用性信息。基于在图11所示的屏幕中输入的信息，酒店管理系统生成可用性和定价信息。如图所示，在屏幕1202的顶部，表明了和旅馆代码1204、房间类型1206、到达日期1208、离开日期1210、货币1212、成人数1214以及儿童数1216相关的信息。在屏幕1202的下部，显示了所请求房间类型的可用价格1218。为每一间可用房间提供的信息包括合同代码1220、房间类型1222、房间级别1224、总费用1226、货币(例如MXM：比索)1228以及每逗留一晚的费用1230。房间级别1224是一定价级别，它由收入管理者根据酒店管理系统所实现的复杂实时信息处理来设置。这种处理的例子在图7示出。如果预计会非常需要房间和/或各个设施，则可以提升房间级别，表明价格提升到房间的基本价格以上。通过激活“添加(Add)”按钮1232，可以选择所感兴趣的房间。尽管未示出，然而一旦选择了所感兴趣的房间或其它设施，则在平面上提供预约细节的概要，供代理确认这些要求和顾客的要求相匹配。一旦确认了这一信息，就可以通过确保提交了必要的付款来结束预订。当确认了预约时，另一屏幕(未示出)说明了预订确认。

图13示出可以从图12的说明性屏幕或另一类似屏幕访问的价格细节窗口1302。如图所示，价格细节基于日期1304、旅馆1306、合同1308、房间类型1310和日常价格1312来提供。房价细节在房价调节历史部分1314中示出，该部分1314表明了房价怎样由于不同因素而变化。房价不可供使用的原因在部分1316中示出。例如，房价不可用可能因为它被一价格阻碍1318所终止(closed)。价格阻碍一般定义了酒店管理系统对于一特定的预订可接受的最低价格，并且由收入管理系统(即收入管理引擎和收入管理人员)设置。

价格细节1302向不同商业实体的管理者或管理团队提供了有价值的信息。通过使用价格细节窗口1302中可用的信息，他们能组织和确定人员安排要求，并且接入特定价格不可用的原因。这使管理层或管理者能解释顾客所观察到的任何定价差异，或者它仅仅通过给出关于价格在特定期间上涨或下降的明确原因，使他们能注意顾客关系。同样，由于管理团队或管理者不用设置价格，他们能更容易地专注于商业实体的运营。

图14说明了用于本发明一方面的一实施例中酒店组织的用户界面(这里是因特网主页的屏幕快照)1402的实施例。通过使用主页屏幕1402，顾客能输入他们希望逗留的细节。例如，顾客可以输入所需的信息，比如所感兴趣的城市1404、期望的旅馆1406、预订日期1408、人数1410以及为得到点数或可能的折扣的会员信息1412、以便检验可用性并作出预订。其它信息也在网站可用，比如但不限于：气象信息1414、货币兑换1416、地图1418、促销1419等。顾客也能通过选择在线预约1420而直接开始一在线的预约过程。

图15说明了根据本发明一方面的一实施例、由销售人员自动化(SFA)系统为团体预约而使用的网页1502的用户界面屏幕快照的实施例。如图所示，销售代理或销售执行者可以从一旅馆列表1504中选择多个商业实体。通过选择旅馆并激活添加按钮1508，每个所选的旅馆(例如Fiesta Inn Acapulco)可以被添加到选择窗口1506。一旦已经把一特定团体所感兴趣的旅馆以及逗留日期1510添加到选择窗，欧1506，就激活搜索按钮1512。基于中央编目系统所处理的搜索，基于所指示的逗留日期，为和所选旅馆(例如Fiesta Inn Acapulco)相关联的不同房间1516提供定价1514。

图16说明了根据本发明一方面的一实施例的用户界面的实施例，该用户界面的形式为收入管理者(人)或收入管理团队所使用的网页屏幕1602。该屏幕使收入管理者能手工地覆盖为一特定的商业实体(比如旅馆1604)计算的定价。对于特定的房间类型1606，收入管理者可以把一定价手工地输入到格子1608。

无论不同代理(组织的销售代理、或个人)所使用的各种网页的不同“外观感受(look-and-feel)”，为被输入网页的处理信息而使用的预订引擎和基本商业逻辑是相同的。如图3所述，应用接口(第一层)处理不同的网页信息，其中信息被继续传送到第二层商业规则逻辑。因此，被输入主页(图14)或经过电话预约服务(图11)的信息由应用服务器(图3)内的同一预订引擎所处理。

除了上述本发明各方面的实施例以外，并且根据于2003年1月24日提交的第60/442,198号美国临时专利申请(其内容通过引用被完全结合于此)，本领域的技术人员将会得出多种其它的排列和步骤，如果这些排列和步骤未在该文档中明确描述，也能体现本发明的原理并且落在所附权利要求的范围之内。例如，方法步骤的顺序不必要是固定的，而是能被修改而不背离本发明的范围和精神。

Claims (66)

1.一种用于管理一酒店组织的方法，所述酒店组织具有提供一个或多个相应设施的地理上分布的商业实体，其中通过多个渠道的一个或多个作出和商业实体所提供的设施使用相关的布局，所述方法包括以下步骤：

(a)为所述商业实体和与商业实体相关的相应设施维持一中央编目系统；

(b)经由所述多个渠道的至少一个接收对和至少一个商业实体的至少一个设施相关联的定价方案的请求；

(c)响应于对和所述至少一个设施相关的定价方案的请求，基于中央编目系统中驻留的数据生成一报价；以及

(d)响应于对所述定价方案的请求，通过所述多个渠道的至少一个发送所述报价。

2.如权利要求1所述的方法，其特征在于，不使用仅由商业实体持有的数据而生成所述报价。

3.如权利要求1所述的方法，其特征在于，对报价的请求直接从顾客接收到。

4.如权利要求1所述的方法，其特征在于，所述酒店组织包括销售人员，对报价的请求从一销售人员接收到，所述报价被发送到所述销售人员。

5.如权利要求1所述的方法，其特征在于，所述商业实体雇用相应的人员，对报价的请求关于商业实体的一设施并且从所述商业实体人员接收到，所述报价被发送到所述商业实体人员。

6.如权利要求1所述的方法，其特征在于，所述报价是实时生成的。

7.如权利要求1所述的方法，其特征在于，所述报价是用中央编目系统中驻留的实时数据生成的。

8.如权利要求6所述的方法，其特征在于，所述报价是用中央编目系统中驻留的实时数据生成的。

9.如权利要求1所述的方法，其特征在于，中央编目系统接收对报价的请求所通过的渠道包括这样的渠道：通过所述渠道，所述报价一旦已生成就响应于该请求而被发送。

10.如权利要求1所述的方法，其特征在于还包括以下步骤：接收对报价的接受情况并且临时分配和所述报价有关的至少一个设施。

11.如权利要求1所述的方法，其特征在于还包括以下步骤：接收对临时分配的至少一个设施的付款。

12.如权利要求11所述的方法，其特征在于还包括完全分配所述至少一个设施的步骤。

13.如权利要求10所述的方法，其特征在于还包括以下步骤：更新所述中央编目系统以反映所述临时分配的至少一个设施。

14.如权利要求13所述的方法，其特征在于，所述中央编目系统是实时更新的。

15.如权利要求11所述的方法，其特征在于还包括以下步骤：更新所述中央编目系统以反映接收到对临时分配的至少一个设施的付款。

16.如权利要求15所述的方法，其特征在于，所述中央编目系统是实时更新的。

17.如权利要求12所述的方法，其特征在于还包括以下步骤：更新所述中央编目系统以反映所述至少一个设施的完全分配。

18.如权利要求17所述的方法，其特征在于，所述中央编目系统是实时更新的。

19.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括一全球分布系统。

20.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括和每一个单独的分布式全球设施相关联的财产管理系统。

21.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括一电话预约服务。

22.如权利要求1所述的方法，其特征在于，所述地理上分布式的商业实体包括一旅馆链的财产。

23.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括一指定的销售人员，其中所述指定的销售人员和酒店组织相关联。

24.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括和所述酒店组织相关联的因特网站点。

25.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括用于处理所述请求的第三方因特网站点。

26.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括由所述酒店组织为酒店组织的顾客提供的定制的外联网。

27.如权利要求1所述的方法，其特征在于，所述多个渠道的至少一个包括一动态添加的渠道。

28.如权利要求1所述的方法，其特征在于，所生成的报价独立于接收对报价的请求所通过的渠道。

29.一种用于提供和一酒店组织的地理上分布的商业实体的设施相关联的报价的酒店管理系统，所述酒店管理系统包括：

中央编目系统，其包括一数据存储系统，该数据存储系统用于存储和检取和任一商业实体的设施预订相关联的数据；以及

中央接口，该中央接口与中央编目系统和商业实体通信、并且可由顾客实体访问，以便预订至少一个商业实体的至少一个设施，

所述中央编目系统适用于基于数据存储系统内保存的、并且和商业实体设施相关联的数据来生成报价。

30.如权利要求29所述的酒店管理系统，其特征在于，所述顾客实体包括一顾客。

31.如权利要求29所述的酒店管理系统，其特征在于，所述顾客实体包括酒店组织的销售实体。

32.如权利要求29所述的酒店管理系统，其特征在于，保存在中央编目系统的数据存储系统内并从中检取的数据包括实时数据。

33.如权利要求29所述的酒店管理系统，其特征在于，由所述中央编目系统生成的报价包括实时报价。

34.如权利要求29所述的酒店管理系统，其特征在于，所述中央编目系统还适用于响应于顾客实体接受一报价而预订商业实体的设施。

35.如权利要求29所述的酒店管理系统，其特征在于，所述中央接口适用于从多个渠道接收对报价的请求。

36.如权利要求29所述的酒店管理系统，其特征在于，商业实体的至少一个子集根据和不在该子集中的商业实体所用的过程所不同的过程和酒店管理系统进行电通信，所述中央接口适用于不考虑不同的过程而与商业实体通信。

37.如权利要求36所述的酒店管理系统，其特征在于，所述过程包括数据格式。

38.如权利要求29所述的酒店管理系统，其特征在于还包括和所述中央编目系统通信的收入管理系统，所述收入管理系统适用于根据多个数据源并且在报价所提出的条件下为商业实体的设施生成报价，所述数据源对于向其请求报价的设施的经济价值有潜在的影响。

40.如权利要求38所述的酒店管理系统，其特征在于，所述多个数据源包括来自中央编目系统的实时数据。

41.如权利要求29所述的酒店管理系统，其特征在于，所述中央编目系统包括用于控制数据存储系统中的数据的存储和检取的处理系统。

42.如权利要求41所述的酒店管理系统，其特征在于，所述处理系统基于所检取的数据生成所述价格报价。

43.如权利要求42所述的酒店管理系统，其特征在于，所检取的数据包括实时数据，所述价格报价基于所检取的实时数据实时地生成。

44.如权利要求29所述的酒店管理系统，其特征在于，数据存储系统中存储的和任一商业实体的设施预订相关的数据包括实时数据。

45.如权利要求29所述的酒店管理系统，其特征在于，所述中央接口包括一公布/预订系统。

46.如权利要求29所述的酒店管理系统，其特征在于还包括和中央编目管理系统通信的商业智能系统，用于访问和处理和任一商业实体的设施预订相关联的数据、以生成顾客专用的服务优选项。

47.如权利要求46所述的酒店管理系统，其特征在于，所述顾客专用的服务优选项包括从由房间优选项和优选的舒适度组成的组中选择的至少一个。

48.一种运营酒店组织的中央编目系统的方法，所述酒店组织具有多个地理上分布的商业实体，所述方法包括以下步骤：

(a)维持和所述中央编目系统相关的数据库，所述数据库包括和所述多个商业实体的设施有关的中央生成的价格和可用性数据；

(b)接收对所述多个商业实体的至少一个设施的预订请求；

(c)基于所述预订请求，从所述数据库检取和所述设施有关的数据；

(d)处理所检取的数据以生成对所述设施的报价；

(e)响应于所述预订请求而发送所述报价；

(f)接收反映出接受报价的信号；以及

(g)基于接收到反映接受报价的信号而更新所述数据库。

49.如权利要求48所述的运营中央编目系统的方法，其特征在于，所述数据库在实时基础上维持。

50.如权利要求48所述的运营中央编目系统的方法，其特征在于，和所述设施有关的所检取的数据包括价格设置数据。

51.如权利要求50所述的运营中央编目系统的方法，其特征在于，所述设施具有一给定的类型并且有给定的特征，所述价格设置数据基于从以下内容组成的组中选择的至少一个而导出：和设施类型和特征有关的市场分析；和设施类型和特征有关的策略考虑；对具有给定类型和特征的设施的需求预报；对具有给定类型的设施的定价优化方法；以及对先前预订的给定类型设施的收益性的监视。

52.一种用于管理一酒店组织的地理上分布商业实体的设施定价和预订的中央系统，所述中央系统包括：

(a)中央编目系统，用于维持和设施的定价和预订相关的单个数据储存库；

(b)通过一网络和中央编目系统通信的应用服务器，所述应用服务器可由中央编目系统为预订所述设施而通过网络进行访问；以及

(c)和中央编目系统、应用服务器以及至少一个外部系统进行通信的中央接口，用于支持中央编目系统、应用服务器和至少一个外部系统之间的通信。

53.如权利要求52所述的中央系统，其特征在于，和所述设施的定价和预订相关的数据包括实时数据。

54.如权利要求52所述的中央系统，其特征在于，所述外部系统包括由一顾客实体所运行的系统。

55.如权利要求52所述的中央系统，其特征在于，所述外部系统包括由酒店组织的多个商业实体之一所运行的系统。

56.如权利要求52所述的中央系统，其特征在于，所述至少一个外部系统包括和酒店组织的商业实体相关联的财产管理系统。

57.如权利要求52所述的中央系统，其特征在于，所述至少一个外部系统包括一销售支持系统。

58.如权利要求52所述的中央系统，其特征在于，所述至少一个外部系统包括基于中央编目系统数据来优化收入的收入管理系统。

59.如权利要求52所述的中央系统，其特征在于，所述至少一个外部系统包括一全球分布系统(GDS)。

60.如权利要求52所述的中央系统，其特征在于，所述设施包括一旅馆链的财产。

61.一种用于管理一酒店组织的多个商业实体之一的方法，所述方法包括：

(a)通过一网络从相对于多个商业实体在集中化的编目系统接收和所述商业实体的设施预订相关联的数据；以及

(b)基于从集中化系统接收到的预订数据来分配商业实体的资源。

62.如权利要求61所述的方法，其特征在于还包括以下步骤：通过所述网络从中央编目系统访问和设施预订相关联的定价数据。

63.如权利要求61所述的方法，其特征在于还包括以下步骤：制止为所述商业实体的设施确定一价格。

64.如权利要求61所述的方法，其特征在于，所述酒店商业实体包括一旅馆。

65.如权利要求61所述的方法，其特征在于，所述酒店商业实体包括一游船。

66.如权利要求62所述的方法，其特征在于，从中央编目系统接收到的定价数据在持续基础上被更新。

67.如权利要求66所述的方法，其特征在于，所述定价数据反映出用一收入管理系统优化的定价。

Images