确定针对住宿列表的主人偏好的制作方法

本发明涉及住宿预订系统，并且具体地涉及当接收到针对住宿列表的预约请求时确定主人偏好。

背景技术：

在线预订系统匹配寻找短期住宿的客人与提供住宿的主人。主人通常具有某些偏好，该偏好影响针对住宿的特定请求被主人接受还是拒绝。这样的偏好可以由主人明确提供，诸如不允许宠物的指示，或者住宿仅在周末可用的指示。然而，最经常地，偏好是隐含的，并且取决于不容易被量化的若干变量。因此，可能难以确定针对预约的特定请求将被接受还是拒绝。

技术实现要素：

在线预订系统基于先前接收的预约请求的特征与主人对那些预约请求的接受之间的统计关系来对主人的偏好建模。具体地，系统基于特征的集合来对预约请求分类。基于拥有该特征的预约请求与主人所接受的预约请求之间的关系来对主人对于特定请求特征的偏好建模。系统使用针对给定列表的偏好模型来确定主人将接受对列表的预期预约请求的概率。概率可以用于通过降低预期预约请求具有被主人接受的低概率的搜索结果的呈现排名或滤除该搜索结果来生成精确的搜索结果。

在某些情况下，生成精确的偏好模型所需的足够的历史数据不可用。为了解决该数据不足，基于针对给定列表的历史数据结合针对相同地区的其他列表的历史数据来生成偏好模型。

本发明内容和以下详细描述中描述的特征和优点不是全部包括性的。鉴于附图、说明书和权利要求，很多附加的特征和优点对于本领域普通技术人员将是显而易见的。

附图说明

图1是根据一个实施例的在线预订系统的系统图。

图2是示出根据一个实施例的在线预订系统中包括的不同模块和储存库的框图。

图3是根据一个实施例的在线预订系统的类图的图示。

图4是根据一个实施例的被配置为基于区域数据来生成列表特定的偏好模型的主人偏好模块229的详细图示。

图5是根据一个实施例的用于基于区域数据来生成列表特定的预约请求偏好模型的示例性方法的流程图。

图6a是根据一个实施例的用于基于与列表相关联的数据来生成针对列表的局部偏好模型的示例性方法的流程图。

图6b是根据一个实施例的用于基于全局数据来生成全局偏好模型的示例性方法的流程图。

图7是根据一个实施例的用于基于偏好模型来生成针对搜索查询的搜索结果的示例性方法的流程图。

附图仅出于说明的目的描绘本发明的各种实施例。本领域技术人员将从以下讨论中容易地认识到，在不脱离本文中所描述的本发明的原理的情况下，可以采用本文中所示的结构和方法的备选实施例。

具体实施方式

系统概述

图1是根据一个实施例的在线预订系统的系统图。图1和其它附图使用相同的附图标记来标识相同的元件。诸如“113a”的在附图标记之后的字母指示文本具体涉及具有该特定附图标记的元素。诸如“113”的没有随后的字母的文本中的附图标记是指附图中具有该附图标记的元素中的任何或全部元素(例如，文本中的“113”在图中是指附图标记“113a”和/或“113b”)。

网络105表示用户103(例如消费者)和在线预订系统111之间的通信路径。在一个实施例中，网络是因特网。网络还可以利用不一定是因特网的一部分的专用或私有通信链路(例如广域网(wan)、城域网(man)、或局域网(lan))。网络使用标准通信技术和/或协议。

客户端设备101被用户103用来与在线预订系统111交互。客户端设备101可以是任何设备，其是或并入计算机，诸如个人计算机(pc)、台式计算机、膝上型计算机、笔记本计算机、智能电话等。计算机是具有一个或多个通用或专用处理器、存储器、存储装置和网络组件(有线或无线)的设备。客户端设备101执行操作系统，例如microsoftwindows兼容的操作系统(os)、appleosx或ios、linux发行版或者google的androidos。在一些实施例中，客户端设备101可以使用诸如microsoftinternetexplorer、mozillafirefox、googlechrome、applesafari和/或opera的web浏览器113作为与在线预订系统111交互的界面。在其他实施例中，客户端设备101可以执行用于访问在线预订系统111的专用应用。

在线预订系统111包括web服务器109，其呈现形成用户103可见的基本界面的web页面或其他web内容。用户103使用相应的客户端设备101访问一个或多个web页面，并且通过界面向在线预订系统111提供数据。

在线预订系统111可以是例如在线预订系统、餐饮预约系统、共乘预约系统、零售系统等。更一般地，在线预订系统111向用户提供对消费者可用的资源(例如商品和服务)的库存的访问。每个资源的现实世界物理位置被认为是消费者决定消耗(例如购买、租赁或以其他方式获取)资源的因素。其他因素包括列表类型、列表所有者的身份、以及先前已经使用由列表提供的服务的用户的评价。

在一些实施例中，在线预订系统111有助于用户103之间的交易。例如，在线预订系统允许用户103预订由在线预订系统的其他用户提供的住宿。共乘预约系统允许用户103预订从一个位置到另一位置的乘车。在线市场系统允许用户103与其他用户面对面地购买和/或销售商品或服务。在线预订系统111包括下面描述的附加组件和模块。

在线预订系统

参考图2和图3，在一个实施例中，在线预订系统111包括客人储存库201、主人储存库203、列表储存库205、预约请求储存库213、预订储存库207、消息储存库209、日历211、预订模块215、搜索模块217、接受模块221、可用性模块223和消息传递模块227。本领域技术人员将理解，在线预订系统111可以包含本文中未描述的其他模块。此外，没有示出传统的元件，如防火墙、认证系统、支付处理系统、网络管理工具、负载均衡器，因为它们对本发明不重要。

可以使用单个计算机或计算机网络(包括基于云的计算机实现)来实现系统111。计算机优选地是包括一个或多个高性能cpu和1g或更大的主存储器并且运行诸如linux或其变体的操作系统的服务器类计算机。如本文中所描述的系统111的操作可以通过硬件或通过安装在非暂态计算机存储装置中并由处理器执行以执行本文中所描述的功能的计算机程序来控制。使用非暂态计算机可读存储设备以及用于数据访问和检索的合适的数据库管理系统来实现各种储存库(例如，客人储存库201、主人储存库203等)。系统111包括本文中所描述的操作所需的其他硬件元件，包括网络接口和协议、用于数据输入的输入设备、以及用于显示、打印或数据的其他呈现的输出设备。

客人储存库201持久地存储描述在在线预订系统111中询问针对住宿的列表的用户(即客人)的数据，并且是用于执行该功能的一种手段。每个客人由客人对象301表示，客人对象301也可以被称为客人简档。客人对象301存储与给定客人相关联的唯一标识符和关于该客人的信息。该信息可以包括个人信息，诸如姓名、用户名、电子邮件地址、位置、电话号码、性别、出生日期、个人描述、教育、工作、来自其他用户的评论、图片等。信息还可以包括客人得分311和有经验的标志315。客人得分311提供用户作为客人的先前行为的数值表示。在一些实施例中，客人得分基于由主人根据客人的先前预订而分配的得分(例如评级)。有经验的标志315示出客人是否是在线预订系统111的频繁用户，并且可以例如基于客人通过在线预订系统111预订住宿的总次数、客人最近使用在线预订系统111的次数(例如，客人在过去的60天内预订住宿的次数)、客人使用预订系统111的时间长度、或其组合。

主人储存库203持久地存储描述向在线预订系统111的其他用户提供或愿意提供住宿的用户(本文中为“主人”)的数据，并且是愿意执行该功能的一种手段。每个主人由主人对象303表示，主人对象303也可以被称为主人简档。关于主人的信息包括个人信息，诸如姓名、用户名、电子邮件地址、位置、电话号码、性别、出生日期、个人描述、教育、工作、来自其他用户的评论、图片等。此外，主人储存库203可以存储附加信息，诸如主人得分331、未完成的消息333、过去的客人335、拒绝数目337和时间长度339。每个主人对象303与一个或多个列表305相关联，并且与一个或多个客人对象301相关联。每个主人被分配唯一的主人id。

主人得分331提供用户作为主人的先前行为的数值表示。主人得分可以基于由客人根据主人先前预订而分配的评级。一般来说，每次从主人预订住宿的客人可以提供主人以及住宿的评级。评级然后被聚合成主人得分。评级可以根据客人自己的得分311进行加权，以及基于评级的年龄(即评级有多久)来衰减。

主人还可以使用在线预订系统111从其他主人请求住宿，从而成为客人。在这种情况下，用户将在客人储存库201和主人储存库203中具有简档条目。在线预订系统111的实施例可以将客人储存库201和主人储存库203组合成单个用户简档储存库。然后，用户简档储存库将存储个人信息以及任何客人相关信息和主人相关信息(如果适用)。当用户利用在线预订系统来提供住宿和预约请求住宿时，该方案减少了客人储存库201与主人储存库203之间的冗余信息量。

在线预订系统111通过消息传递模块227使得客人和主人能够相互发送关于住宿的消息。未完成的消息333对来自客人的、主人未响应的消息数目(即等待响应的消息数目)计数。未完成的消息333测量主人对客人的预约请求的响应性。

过去的客人335对主人所提供住宿的客人数目计数。一个实施例自主人开始使用在线预订系统111之后，对主人所提供住宿的客人总数计数。另一个实施例仅考虑主人近期(例如，在过去的30天内)所提供住宿的客人数目。

拒绝数目337对主人拒绝来自预期客人的预约请求的次数计数。主人可能会出于任何数目的原因而拒绝预约请求。例如，来自客人的对于特定住宿的预约请求可能没有遇到足够数目的夜晚；或者住宿实际上不可用，并且主人没有更新列表的日历，如下所述。

时间长度339测量主人通过在线预订系统111提供住宿的时间量。

列表储存库205存储关于由主人通过列表提供的住宿的信息，并且是用于执行该功能的一种手段。给定住宿的每个提供由列表对象305表示。关于列表的信息包括位置351、价格353、单元类型355、便利设施357和日历359。列表储存库205可以包含附加信息，诸如住宿的简短描述、房屋规则列表、照片等。每个列表305被分配唯一的列表id。每个列表305与单个主人对象303相关联。

位置351标识住宿的地理位置，诸如所提供的住宿的完整地址、邻域、城市和/或国家。

价格353是客人为了获得所列出的住宿而需要支付的金额。价格353可以被规定为每天、每周、每天、每个月和/或每个季节或主人规定的其他时间段的金额。另外，价格353可以包括附加费用，诸如清洁费、宠物费和服务费。

单元类型355描述由主人提供的住宿类型。实施例将单元类型分类为两组，房间类型和物业类型。房间类型包括整个家庭或公寓、私人房间和共用房间。物业类型包括公寓、住宅、床和早餐、小木屋、别墅、城堡、宿舍、树屋、船、飞机、停车位、汽车、货车、露营车或休闲车、冰屋、灯塔、蒙古包、尖顶帐篷、山洞、岛、棚屋、土房、小屋、火车、帐篷、阁楼等。

便利设施357列出了住宿提供的附加功能。便利设施包括允许吸烟、允许宠物、tv、有线tv、互联网、无线因特网、空调、暖气、电梯、无障碍设施、游泳池、厨房、免费停车场、门卫、健身房、热水浴池、室内壁炉、蜂鸣器或无线对讲机、早餐、家庭或孩子友善、适合活动、洗衣机、烘干机等。

主人日历359存储由主人规定的或者自动确定的(例如通过日历导入处理)针对日期周期中的每个日期的住宿的可用性。也就是说，主人针对列表访问主人日历359，并且手动地指示列表在哪些日期可用或不可用。主人日历359还包括关于住宿由于已经被客人预订而不可用的日期的信息。此外，主人日历359继续存储关于住宿的可用性的历史信息。此外，主人日历359可以包括日历规则，例如允许的最小和最大数目的夜晚。

预约请求储存库213存储由客人进行的预约请求，并且是用于执行该功能的一种手段。每个预约请求由预约请求对象307表示。关于预约请求存储的信息包括预约请求日期371、入住日期373、夜晚数目375、星期几入住377、星期几退房379、假日381、和客人数目383。每个预约请求307被分配唯一的预约请求id。给定的预约请求307与个体客人301和列表305相关联。

预约请求日期371规定进行预约请求的日期。入住日期373是询问客人需要住宿的第一天。夜晚数目375规定客人需要住宿的夜晚数目。入住日期377和退房日期379规定需要在星期几入住或退房(即星期一、星期二、星期三等)。该信息不需要由客人提供，因为可以其可以从入住日期373和夜晚数目375被推断。该信息是重要的，因为有些主人偏好或仅允许在特定的星期几入住和/或退房(例如，仅在工作日或仅在周末)。假日381指示询问的住宿时段内的假日的日期(如果有)。客人数目383规定住宿的人的总数。

预约请求307可以被预约请求307与其相关联的列表305的主人303接受或拒绝，并且接受的标志385指示预约请求307被主人303接受还是拒绝。如果预约请求307在阈值时间量内不被列表305的主人303接受，则预约请求307也可以到期。在一些实施例中，预约请求307的到期时间由在线预订系统111设置(例如，如果自预约请求307被提交的时间之后的24小时内预约请求307不被接受，则预约请求307到期)。在其他实施例中，预约请求307的到期时间可以由主人303或客人301规定。在其他实施例中，如果预约请求307询问住宿的日期373之前的阈值时间没有被接受，则预约请求307可以到期(例如，如果预约请求307在入住日期373的两天之前没有被接受，则预约请求307可以到期)。

消息储存库209存储通过消息模块227交换的主人103和客人101之间的所有通信，并且是用于执行该功能的一种手段。每个消息与客人101、主人103和列表107相关联。客人可以联系一个或多个主人以获得关于他们相应的列表的更多信息。一些客人也可以使用消息作为获取有关主人的更多信息的手段，反之亦然。

另外，在线预订系统111可以基于主人和客人对传入消息的响应性来向主人和客人分配得分。可以基于每个主人和客人回复的消息的百分比，为每个主人和客人分配响应率得分。还可以基于用户响应传入消息所花费的时间平均时间为用户分配响应时间得分。

主日历211存储指示列表储存库205中的每个列表的可用性的信息，并且是用于执行该功能的一种手段。每个主人负责更新它们在线预订系统111中发布的每个列表的列表日历359。该信息用于形成主日历211。

搜索模块217从客人接收输入查询并且返回与输入查询最佳匹配的住宿列表的列表，并且是用于执行该功能的一种手段。搜索查询包括关于客人的旅行的搜索参数，诸如位置(例如，邮政编码、城市名称和国家)、入住日期、退房日期、客人数目等；以及客人的住宿偏好，诸如房间类型、价格范围、便利设施等。然后，搜索模块检索与搜索查询匹配的所有列表。在一个实施例中，使用布尔匹配用于诸如位置和日期、房间类型和价格范围的参数，其中附加参数用于进一步过滤结果。

在一些实施例中，搜索模块217基于排名得分来对所返回的搜索结果排名。排名得分是多个因素的函数，诸如价格、主人评级、与所偏好的位置的距离、列表、或其组合。排名功能可以被实现为个体因素的线性组合或乘法组合，其中每个因素被表示为指示匹配程度的比例变量(例如，用于底层搜索参数的精确匹配为1，用于部分或近似匹配的0.5)，并且用权重加权以反映该因素的重要性。通常，位置和日期被高度加权，便利设施被较小地加权，但特定权重是系统管理者的设计决策。在一个实施例中，排名因素包括由可用性模块223和接受模块221提供的信息，如下面进一步描述的。

接受模块221计算主人对特定客人针对特定列表的预约请求的接受概率(pc)，并且是用于执行该功能的一种手段。接受模块221的实施例基于主人在历史上接受和拒绝的针对列表的预约请求，针对每个主人使用接受模型。对于满足用户搜索的给定列表，接受模块221计算如果由该客人进行针对给定列表的预约请求，则主人将接受该预约请求的概率。搜索模块217可以在对搜索结果排名或过滤具有低于阈值得分的接受概率的列表时，将接受概率用作排名因素。通常，搜索模块217对具有高的可能性被主人接受的列表排名较高，并且对具有低的可能性被接受的列表排名较低。

预订模块215允许客人301预订通过列表305提供的住宿，并且是用于执行该功能的一种手段。在操作中，预订模块215从客人301接收预约请求307以预约由特定列表305提供的住宿。预约请求包括预约参数，非常类似于搜索查询中的搜索参数，包括入住日期、退房日期和客人数目。预订模块215向与列表305相关联的主人303呈现包括预约参数的预约请求，并且主人303可以接受或拒绝该预约请求。如果主人303接受预约请求，则预订模块215更新指示预约请求被接受的接受标志485，并且还更新预订储存库207，并且在主人接受客人的预约请求时将针对列表的预订日期标记为不可用。预订储存库207存储关于所有被接受和随后预订的住宿预约请求的信息。预订储存库207中的每个条目与主人303、客人301和列表305相关联。

建模主人偏好

对于给定列表305，可能出现关于由主人303接受的预约请求307的类型和由与列表305相关联的主人303拒绝的预约请求307的类型的模式。主人偏好模块229基于针对列表305的预约请求的接受模式对特定列表305的主人303的偏好建模，并且是用于执行该功能的一种手段。偏好模型是列表特定的。因此，对于在线预订系统111中与给定主人相关联的每个列表生成不同的偏好模型。为了便于讨论，针对给定主人和列表组合的偏好模型在下文中被称为列表特定的偏好模型。主人偏好模块229使用列表特定的偏好模型来估计针对列表305的新的预约请求307将被主人303接受的概率。在其他实施例中，偏好模型是主人特定的，并且覆盖由给定主人提供的所有列表；因此每个主人有一个偏好模型。

用于生成偏好模型的数据

为了生成列表特定的偏好模型，主人偏好模块229标识用于对预约请求分类的请求特征的集合。在一个实施例中，请求特征是二元的——预约请求拥有该特征或不拥有该特征。请求特征可能有很多不同类型。具体地，一些请求特征可能与预约请求本身有关。这种请求特征的示例包括预约请求是否针对给定数目或范围的夜晚，预约请求是否针对给定数目或范围的客人，由预约请求规定的夜晚数目是否等于针对列表规定的最大夜晚数目，客人数目是否等于针对列表规定的最大/最小客人数目，所请求的住宿是否落在假日或周末，入住日期和不同预约的先前退房日期之间的间隔是否高于/低于阈值或在范围内，以及预约请求的日/一日中的时间。在其他实施例中，请求特征可以由指示预约请求具有该特征的程度的权重值来表示，以允许部分或模糊匹配。在另一实施例中，请求特征是表示例如夜晚数目的数字变量。

此外，一些请求特征可以与从其接收到预约请求的客人或与列表相关联的主人相关。与客人相关的请求特征的示例包括客人是否有经验，客人的得分是否高于/低于阈值，客人是否已经被验证，以及客人是否具有与他/她的简档相关联的图片。与主人相关的请求特征的示例包括主人是否先前被客人联系，主人是否回复客人，以及主人是否有未完成的消息。本领域技术人员将认识到，上面没有明确列出的其他请求特征在这里在范围内。

主人偏好模块229基于所标识的请求特征的集合和存储在客人储存库201、主人储存库203、列表储存库205、消息储存库209和预约请求储存库213中的历史数据来生成针对每个预约请求的特征向量。对于给定的预约请求，特征向量包括针对每个请求特征的二进制值，以形成位向量。如果预约请求拥有该特征，则二进制值表示“1”或“真”。相反，如果预约请求不拥有该特征，则二进制值表示“0”或“假”。对于本讨论的剩余部分，请求特征也被称为fx,，其中每个x表示请求特征的类型。然后，对于给定的预约请求，特征向量采用以下形式[fa,fb,fc,...,fn]，其中针对fa,fb,fc,...,和fn中的每个的二进制值取决于预约请求是否拥有该特征。特征向量还包括接受值，其指示针对该列表的预约请求被主人接受还是拒绝。对于本讨论的剩余部分，接受值特征也被称为a。如所指出的，在另一实施例中，可以通过权重来表示请求特征，以形成实数的向量(例如，0和1之间的值)、或者二进制和实数的组合。

通常，没有足够的历史数据可用于创建精确的列表特定的偏好模型。为了解决该数据不足，主人偏好模块229可以采用两种不同的方法。在第一种方法中，针对第一列表的历史数据使用针对与第一列表具有一个或多个公共属性的其他列表的历史数据来被增强(在本文中称为“集群方法”)。图4和图5以及对应的描述包括集群方法的细节。在第二种方法中，使用针对所有列表的历史数据而不是特定于列表或区域的数据(在本文中称为“个体方法”)。图6和对应的描述包括个体方法的细节。使用这两种方法，所生成的偏好模型允许主人偏好模块229估计针对列表的未来的预约请求将被主人接受的概率。图7和对应的描述包括使用偏好模型来改进被呈现给预期客人的搜索结果的细节。

生成偏好模型的集群方法

在集群方法中，主人偏好模块229基于预约请求集群来生成列表特定的偏好模型。集群包括针对列表的预约请求以及针对与列表具有一个或多个公共属性的其他列表的预约请求。该属性可以是列表在相同地理区域中，具有相同类型(例如，房间类型)，具有相同类型的主人(例如，物业管理者)，或者可以基于协作过滤。与仅与列表相关联的数据相反地，基于集群数据来训练模型，使得主人偏好模块229在与列表相关联的数据不足时能够生成精确的模型。

以下讨论描述了用于为针对相同区域中的列表的预约请求集群生成列表特定的偏好模型的过程。本领域技术人员将容易理解，所描述的过程可以用于为针对具有一个或多个不同的公共属性(诸如具有相同的列表类型或主人类型)的列表的预约请求集群生成列表特定的偏好模型。

图4是根据一个实施例的被配置为基于群集数据生成列表特定的偏好模型的主人偏好模块229的详细图示。如图所示，主人偏好模块229包括集群特征向量生成器401、偏好向量生成器403和偏好相关性生成器405。这些组件的功能细节将在下面参考生成针对位于区域g中并由主人h招待的列表l的列表特定的偏好模型来讨论。

群集特征向量生成器401(也称为“生成器401”)生成用于被包括在特定群集中的针对列表的先前接收的预约请求的集合的集群特征向量，并且是用于执行该功能的一种手段。在操作中，对于列表l，生成器401标识列表l所位于的地理区域g。地理区域可以是由主人偏好模块229确定的邻域、邮政编码、城市、县、国家或任何任意的地理区域。生成器401标识针对列表l的先前接收的预约请求的集合以及针对区域g中的其他列表的预约请求。在一个实施例中，仅选择针对区域g中的所有其他列表的子集的预约请求。可以任意地或者基于列表l和其他列表的子集之间的相似性来选择列表的子集。例如，子集可以是与列表l具有相同的单元类型并且在区域g内的那些列表。此外，可以针对预约请求的集合选择针对给定列表的预约请求的子集。例如，可以仅选择在特定时间段(例如最近六个月)内进行的那些预约请求。

生成器401为预约请求的集合中的每个预约请求生成特征向量。如上所述，针对给定的请求特征的集合，特征向量标识预约请求是否拥有每个请求特征。上面列出了很多不同类型的请求特征，但是假定由生成器401生成的特征向量包括四个特征fa、fb、fc、和fd以及接受值a。在该示例中，fa的值指示所请求的住宿是否落在周末/假日。fb的值指示所请求的住宿是否针对为列表提供的最大夜晚数目。fc的值指示针对所请求的住宿的入住日期是否在针对先前预订的退房日期之后的至少1整天。fd的值指示主人先前是否曾被客人联系。a的值指示主人接受还是拒绝了预约请求。

对于每个特征向量，生成器401访问在线预订系统111中存储使得生成器401能够确定相关联的预约请求是否拥有每个请求特征的数据的一个或多个相关的储存库。例如，对于fa，生成器401访问预约请求储存库312以确定进行预约请求的具体日期。如果日期落在周末/假日，则fa设置为“1”。如果日期没有落在周末/假日，则fa设置为“0”。类似地，对于fb，生成器401访问预约请求储存库312以确定进行预约请求的夜晚数目。生成器401还访问列表储存库205以确定为列表规定的最大夜晚数目。如果数目匹配，则fb设置为“1”。如果数目不匹配，则fb设置为“0”。以这种方式，生成器401访问不同储存库中的数据以填充针对预约请求的集合中的每个预约请求的特征向量。

生成器401然后组合针对预约请求的集合的个体特征向量以生成表示预约请求的集合的群集特征向量。例如，如果在区域g中存在包括列表l的三个列表，则将针对三个列表的预约请求的特征向量组合以生成群集特征向量。假定在这样的示例中，针对三个列表进行了五个预约请求。群集特征向量可以采用以下形式：

其中向量的每列对应于fa、fb、fc、fd和a中的一个，并且每行对应于针对三个列表中的一个列表的不同的预约请求。在该示例中，前两行可以对应于针对列表l的预约请求1和预约请求2，行三和四可以对应于针对区域g中的列表m的预约请求1和预约请求2，并且最后一行可以对应于针对区域g中的列表n的预约请求1。

偏好向量生成器403(也称为“生成器403”)处理群集特征向量以生成列表特定的偏好向量，并且是用于执行该功能的一种手段。列表特定的偏好向量标识针对每个请求特征的特定列表的主人的偏好值。偏好向量采用以下形式：[βla,βlb,βlc,...,βln]。

为了计算列表特定的偏好向量，生成器403首先计算群集特征向量中的针对每个请求特征的群集偏好值。针对给定请求特征的集群偏好值通过计算跨所有的由集群特征向量表示的预约请求或列表的偏好的平均或中值，来组合集群中的所有列表(例如相同区域中的列表)的偏好。在一个实施例中，使用以下公式来计算集群偏好值：

其中βx是针对给定请求特征的集群偏好值，t是由集群特征向量表示的预约请求的总数，fx是针对由集群特征向量表示的给定预约请求的请求特征的值，并且a是指示主人是否接受预约请求的值。

使用针对列表l-n的预约请求继续上述示例，可以通过评估以下等式来计算针对请求特征fa的集群偏好值βa。在评估时，βa的值为～0.67。

一旦为每个请求特征计算了群集偏好值，则生成器403可以计算针对特定列表的列表特定的偏好向量。同样，列表特定的偏好向量标识针对每个请求特征的特定列表的主人的偏好值。在操作中，生成器403基于针对该特征的集群偏好值和局部偏好值的组合来计算针对每个请求特征的列表特定的偏好值。针对给定请求特征的局部偏好值指示跨针对特定列表的所有预约请求的针对请求特征的中值或平均偏好。在一个实施例中，使用以下公式计算局部偏好值：

其中βlx是针对给定请求特征的列表特定的偏好值，yl是针对列表l的在集群特征向量中表示的预约请求的总数，fx是针对在集群特征向量中表示的给定预约请求的请求特征的值，a指示该预约请求被主人接受还是拒绝，并且k是要分配给针对请求特征的集群偏好值的权重。

使用针对列表l-n的预约请求继续上述示例，可以通过评估以下等式来计算针对请求特征fa的列表特定的偏好值βla。在下面的等式中，权重k被设置为0.5。任何其他合适的权重都在范围内。在评估时，βla的值为～0.13。

如上所述，列表特定的偏好值[βla,βlb,βlc,...,βln]形成列表特定的偏好向量。偏好模型生成器405(也称为“生成器405”)基于列表特定的偏好向量来生成针对列表的列表特定的偏好模型，并且是用于执行该功能的一种手段。为了生成模型，生成器405首先生成针对模型的训练数据集。通过将列表特定的偏好向量应用于由群集特征向量表示的针对列表的预约请求的特征向量来生成训练数据集。具体地，对于给定的特征向量，每个请求特征的值乘以针对该请求特征的列表特定的偏好值以生成偏好得分。所得到的特征向量的集合形成针对模型的训练数据集。

生成器405接着基于训练数据集来估计每个偏好对主人最终接受还是拒绝预约请求的影响。每个偏好的所估计的影响是偏好模型的参数，并且参数的集合形成偏好模型。在一个实施例中，生成器405使用逻辑回归来计算偏好模型的参数，逻辑回归标识由a表示的预约请求的接受或拒绝与请求特征之间的统计关系。具体地，生成器405建立与由群集特征向量表示的每个预约请求相关联的等式。每个等式采用如下形式：

a＝θo+[θa×βla·fa]+[θb×βlb·fb]+[θc×βlc·fc]+[θd×βld·fd]

其中a是指示预约请求被接受还是拒绝的值，θo是参数模型的常数参数，θa是参数模型的指示fa和a之间的统计关系的参数，βla·fa是训练数据集中的针对请求特征fa的偏好得分，θb是参数模型的指示fb和a之间的统计关系的参数，βlb·fb是训练数据集中的针对请求特征fb的偏好得分，θc是参数模型的指示fc和a之间的统计关系的参数，βlc·fc是训练数据集中的针对请求特征fc的偏好得分，θd是参数模型的指示fd和a之间的统计关系的参数，βld·fd是训练数据集中的针对请求特征fd的偏好得分。

然后，生成器405处理等式以估计针对参数θo、θa、θb、θc和θd的值。总体上，参数形成与该区域中包含的列表集合相关联的偏好模型。偏好模型可以用于估计列表的主人将接受针对列表的将来的预约请求的概率。如下面结合图7详细讨论的，可以使用这样的概率对针对列表的搜索结果进行排名和过滤。

图5是根据一个实施例的基于区域数据来生成列表特定的预约请求偏好模型的示例性方法的流程图。图5中的方法在生成针对列表l的偏好模型的上下文中描述。该方法开始于主人偏好模块229标识501针对在列表l所位于的地理区域中的包括列表l的列表的预约请求的集合。每个预约请求先前已经被列表的主人接受或拒绝。

主人偏好模块229基于所标识的预约请求的集合的特征来生成503群集特征向量。具体地，主人偏好模块229首先为预约请求的集合中的每个预约请求生成特征向量。每个特征向量指示预约请求是否拥有请求特征的集合中的每个请求特征。针对预约请求的集合的特征向量共同形成群集特征向量。

主人偏好模块229基于所生成的集群特征向量来生成505针对列表l的列表特定的偏好向量。列表特定的偏好向量包括针对每个请求特征的列表l的主人的偏好值。为了生成列表特定的偏好向量，主人偏好模块229首先跨由群集特征向量表示的所有列表计算针对每个请求特征的区域中值或平均偏好。区域中值或平均偏好与主人针对请求特征的偏好相结合，以计算针对请求特征的列表l的主人的偏好值。

基于列表特定的偏好向量，主人偏好模块229生成507针对列表l所属的区域的偏好模型。偏好模型指示预约请求的接受与每个请求特征之间的统计关系。为了确定模型，生成器405首先生成针对模型的训练数据集。通过将列表特定的偏好向量应用于针对该区域中的列表的预约请求的特征向量来生成训练数据集。然后，主人偏好模块229基于训练数据集来估计预约请求的接受、每个请求特征和主人/列表偏好之间的统计关系。所估计的统计关系是偏好模型的参数，并且参数的集合形成偏好模型。

主人偏好模块229与列表所属的区域相关联地将偏好模型存储509在模型储存库231中。可以基于与针对列表l和/或该区域中的其他列表的新的预约请求相关联的数据周期性地更新偏好模型。

生成偏好模型的个体方法

在个体方法中，主人偏好模块229生成两个偏好模型：(i)基于针对列表的预约请求生成的局部偏好模型，以及(ii)基于在线预订系统111中可用的跨所有列表的预约请求生成的全局偏好模型。图6a描述了用于生成局部偏好模型的过程，图6b描述了用于生成全局偏好模型的过程。当与列表相关联的数据足以生成精确的模型时，使用局部偏好模型来预测针对列表的未来的预约请求被接受的概率。当与列表相关联的数据不足时，使用全局偏好模型来预测针对未来的预约请求被接受的概率。

图6a是根据一个实施例的用于基于与列表相关联的数据来生成针对列表的局部偏好模型的示例性方法的流程图。图6a中的方法在生成针对列表l的偏好模型的上下文中描述。该方法开始于主人偏好模块229标识501针对列表l的预约请求的集合。每个预约请求先前被列表l的主人接受或拒绝。

主人偏好模块229基于所标识的预约请求的集合的特征来生成603列表特定的特征向量。列表特定的特征向量包括针对预约请求的集合中的每个预约请求的向量。对于给定的预约请求，特征向量标识预约请求是否拥有请求特征的集合中的每个请求特征。假定生成器401生成的特征向量包括四个特征fa、fb、fc、fd以及接受值a。主人偏好模块229组合针对预约请求的集合的个体特征向量，以生成表示预约请求的集合的列表特定的特征向量。例如，假定已经针对列表l进行了五个预约请求。因此针对列表l的列表特定的特征向量可以采用如下形式：

其中向量的每列对应于fa、fb、fc、fd和a中的一个，并且每行对应于针对列表l的不同的预约请求。

基于列表特定的特征向量，主人偏好模块229生成607针对列表l的局部偏好模型。局部偏好模型指示针对列表l的预约请求的接受与每个请求特征之间的统计关系。基于列表特定的特征向量生成针对局部偏好模型的训练数据集。主人偏好模块229基于训练数据集来估计预约请求的接受与每个请求特征之间的统计关系。每个请求特征的所估计的统计关系是偏好模型的参数，并且参数的集合形成偏好模型。

在一个实施例中，主人偏好模块229使用逻辑回归来计算局部偏好模型的参数，逻辑回归标识由a表示的预约请求的接受或拒绝与请求特征之间的统计关系。具体地，主人偏好模块229设置一组等式，每个等式与针对列表l的由列表特定的特征向量表示的不同预约请求相关联。每个等式采用以下形式：

a＝γo+[γa×fa]+[γb×fb]+[γc×fc]+[γd+fd]

其中a是指示预约请求被接受还是拒绝的值，γo是参数模型的常数参数，γa是参数模型的指示fa和a之间的统计关系的参数，fa是列表特定的特征向量中的针对请求特征fa的值，γb是参数模型的指示fb和a之间的统计关系的参数，fb是列表特定的特征向量中的针对请求特征fb的值，γc是参数模型的指示fc和a之间的统计关系的参数，fc是列表特定的特征向量中的针对请求特征fc的值，并且γd是参数模型的指示fd和a之间的统计关系的参数，fd是列表特定的特征向量中的针对请求特征fd的值。主人偏好模块229然后处理等式来估计参数：γo、γa、γb、γc和γd的值。总体上，参数形成与列表l相关联的局部偏好模型。局部偏好模型可以用于估计针对列表的未来的预约请求将被列表的主人接受的概率。

主人偏好模块229与列表l相关联地将局部偏好模型存储607在列表储存库205中。局部偏好模型可以基于与针对列表l的新的预约请求相关联的数据而被周期性地更新。

图6b是根据一个实施例的用于基于全局数据来生成全局偏好模型的示例性方法的流程图。该方法开始于主人偏好模块229标识609在线预订系统111中的与所有列表相关联的预约请求的集合。每个预约请求先前已经被列表的主人接受或拒绝。

主人偏好模块229基于所标识的预约请求的集合的特征来生成611全局特征向量。全局特征向量包括针对预约请求的集合中的每个预约请求的向量。对于给定的预约请求，特征向量标识预约请求是否拥有请求特征的集合中的每个请求特征。假定生成器401生成的特征向量包括四个特征fa、fb、fc和fd以及接受值a。主人偏好模块229组合针对预约请求的集合的个体特征向量以生成表示预约请求的集合的全局特征向量。

基于全局特征向量，主人偏好模块229生成613全局偏好模型。全局偏好模型指示针对任何列表的预约请求的接受与每个请求特征之间的统计关系。基于包括针对跨所有列表的所有预约请求的特征向量的全局特征向量来生成针对全局偏好模型的训练数据集。主人偏好模块229基于训练数据来估计预约请求的接受与每个请求特征之间的统计关系。每个请求特征的所估计的统计关系是全局偏好模型的参数，并且参数的集合形成全局偏好模型。

在一个实施例中，主人偏好模块229使用逻辑回归来计算局部偏好模型的参数，逻辑回归标识由a表示的预约请求的接受或拒绝与请求特征之间的统计关系。本实施例中的逻辑回归的细节与上面用局部偏好模型讨论的相同。

主人偏好模块229将全局偏好模型存储615在列表储存库205中。全局偏好模型可以基于与在线预订系统111中的针对列表的新的预约请求相关联的数据而被周期性地更新。

使用偏好模型改进搜索结果

由主人偏好模块229生成的偏好模型可以由搜索模块217用于以响应于接收到搜索查询来改进被呈现给预期客人的搜索结果。具体地，搜索模块217可以使用偏好模型来确定针对与搜索结果相关联的列表的预约请求将被列表的主人接受的概率。然后，搜索模块217可以根据所确定的概率对搜索结果进行排名和/或过滤具有低于阈值的所确定的概率的某些搜索结果。

图7是根据一个实施例的用于基于偏好模型来生成针对搜索查询的搜索结果的示例性方法的流程图。方法开始于搜索模块217接收701来自客人的搜索查询。搜索查询通常包括定义查询的范围的若干参数。参数可以包括地理区域、单位类型、入住和退房日期、以及客人数目。响应于搜索查询，搜索模块217标识703列表储存库205中满足搜索参数的列表的集合。

对于每个列表，搜索模块217基于与列表相关联的偏好模型来计算705来自客人的针对与搜索查询的参数匹配的列表的预期预约请求将被列表的主人接受的概率。概率的计算取决于主人偏好模块229遵循集群方法还是个体方法而不同。

在集群方法的情况下，搜索模块217选择存储在偏好模块储存库231中的偏好模型。然后，搜索模块217标识在偏好模型中规定的参数，并且将从搜索查询导出的那些参数应用于从搜索查询导出的参数。具体地，搜索模块217将搜索查询分解为请求特征，并且将相关参数应用于每个请求特征。在一个实施例中，使用以下等式将参数应用于预期预约请求：

l＝θo+[θa×βla·fa]+[θb×βlb·fb]+[θc×βlc·fc]+[θd×βld·fd]

其中l是指示预期预约请求将被接受的可能性的值，θo是参数模型的常数参数，θa是偏好模型的指示fa和预约请求的接受之间的统计关系的参数，βla是针对请求特征fa的列表特定的偏好，fa是针对预期预约请求的请求特征的值，θb指示给定的主人偏好βlb与预约请求的接受之间的统计关系，βld是针对请求特征fb的列表特定的偏好，fb是针对预期预约请求的请求特征的值，θc是指示fc和预约请求的接受之间的统计关系的偏好模型的参数，βlc是针对请求特征fc的列表特定的偏好，fc是针对预期预约请求的请求特征的值，θd是指示fd和预约请求的接受之间的统计关系的偏好模型的参数，βld是针对请求特征fd的列表特定的偏好，并且fd是针对预期预约请求的请求特征的值。

在一个实施例中，来自上述等式的l(即预期预约请求将被接受的可能性)使用以下逻辑公式被转换成概率：

在主人偏好模块229遵循个体方法的情况下，搜索模块217在全局偏好模块和与列表相关联地存储的局部偏好模块之间进行选择。搜索模块217基于针对列表接收到的历史预约请求数目进行选择，局部偏好模块基于该历史预约请求而被生成。当预约请求数目低于阈值时，搜索模块217将全局偏好模型的参数应用于预期预约请求。当预约请求数目高于阈值时，搜索模块217将局部偏好模型的参数应用于预期预约请求。用于将全局偏好模型或局部偏好模型应用于预期预约请求的机制与上面关于集群方法讨论的机制相同。在一个实施例中，当预约请求数目高于阈值时，搜索模块217基于全局偏好模型来计算全局概率并且基于局部偏好模型来计算局部概率。然后将两个概率组合以生成预期预约请求被接受的概率。

一旦为所标识的列表计算了接受的预约请求的概率，则搜索模块217基于所计算的概率来将列表呈现707给预期客人。在一个实施例中，搜索模块217基于所计算的概率对列表进行排名。其他功能(诸如列表的质量、价格等)可以进一步影响列表的排名。在另一实施例中，搜索模块217将具有低于阈值的所计算的概率的列表过滤而不呈现。

替代应用

鉴于附图、说明书和权利要求书，本说明书中描述的特征和优点不是全部包括性的，并且具体地，很多附加特征和优点对于本领域普通技术人员将是显而易见的。此外，应当注意，说明书中使用的语言主要是为了可读性和指导目的而选择的，并且不被选择来描绘或限制本发明的主题。

为了说明的目的已经呈现了本发明的实施例的前述描述；但并不旨在穷举或将本发明限制于所公开的精确形式。相关领域的技术人员可以理解，鉴于上述公开内容，很多修改和变化是可能的。

本说明书的一些部分在关于信息的操作的算法和符号表示方面来描述本发明的实施例。这些算法描述和表示是数据处理领域的技术人员通常使用的，以便有效地将其工作的实质传达给本领域技术人员。在功能上、计算上或逻辑上描述的这些操作被理解为由计算机程序或等效电路、微代码等实现。此外，有时也可以方便地将这些操作布置称为模块，而不失一般性。所描述的操作及其相关联的模块可以以软件、固件、硬件或其任何组合来实施。

本文中所描述的任何步骤、操作或过程可以单独地或与其他设备组合地用一个或多个硬件或软件模块来执行或实现。在一个实施例中，使用计算机程序产品来实现软件模块，该计算机程序产品包括包含计算机程序代码的计算机可读介质，计算机程序代码可以由计算机处理器执行以执行所描述的任何或全部步骤、操作或处理。

本发明的实施例还可以涉及用于执行本文中的操作的装置。该装置可以为所需目的而特别构造，和/或其可以包括由存储在计算机中的计算机程序选择性地激活或重新配置的通用计算设备。这样的计算机程序可以存储在有形的计算机可读存储介质或适于存储电子指令的任何类型的介质中，并且耦合到计算机系统总线。此外，在本说明书中提到的任何计算系统可以包括单个处理器，或者可以是采用多个处理器设计以提高计算能力的架构。

最后，本说明书中使用的语言主要是为了可读性和指导目的而选择的，并且不被选择来描述或限定本发明的主题。因此，意图是本发明的范围不受该详细描述的限制，而是由在基于此的申请上发布的任何权利要求来限制。因此，本发明的实施例的公开旨在说明而不是限制在所附权利要求中阐述的本发明的范围。