CN105164706A - 针对用户源的住处的预订可用性的自动确定 - Google Patents

Abstract

公开了用于更新针对住处列表的日历条目的方法和系统。在一个实施例中，方法包括生成针对住处预订系统中的住处列表的可用性模型和接受模型，并且基于那些模型确定住处列表将能够被预订的概率。此外，可以使用所确定的预订概率对住处搜索查询的结果进行过滤和/或分类。

Description

针对用户源的住处的预订可用性的自动确定

技术领域

本发明涉及住处预订系统，并且更特别地涉及根据先前预订历史来预测住处的预订可用性。

背景技术

一些现有的住处预订系统(诸如住处加早餐预订系统或者备选的寄宿预定系统)允许用户张贴针对其拥有或者占据的寄宿的住处供给。从公寓的单个房间到整个城堡，web服务(诸如Airbnb或者HomeAway)让用户提供其寄宿并且将其展现给数百万的受众。在大部分情况下，住处预订系统的用户不是专业旅行经营者并且使用通过住处预订系统所获得的收入作为次要收入。

住处预订系统还让其他用户寻找住处以通过提供非常规类型的寄宿来获得独特的旅行体验。住处预订系统将寻找短期住处需要的用户与寻找出租其寄宿的其他用户进行匹配。

将其住处提供给他人的用户录入关于住处的信息以及关于各个日期的住处的可用性的信息。虽然所提供的信息通常是准确的，但是诸如可用性的一些信息需要周期性地被更新。在大部分情况下，张贴住处供给的用户负责保持可用性信息最新，这指示哪些日期住处将是或者将不是可用的。然而，现有系统不提供确保用户实际上保持可用性信息最新的任何方式。由于对于大部分用户而言，住处预订系统不是其主要收入来源，因而他们偶发地更新其列表信息。这可以使得寻找住处的用户在搜索结果中获得似乎对于期望的时间段可用但是实际上并不可用的列表。然后，用户将浪费时间查看不匹配其需要的列表。那些用户还可以请求来自那些列表的住处和/或向发布列表的用户发送请求附加信息的消息。这将减少用户请求住处预订系统上的住处的信心，并且还可能减小用户将通过住处预订系统得到住处的可能性。

发明内容

住处预订系统可以基于住处的当前所列出的可用性和更新住处的可用性信息中的住处的主人的过去行为，来预测针对给定时间段的住处的可用性。在一个实施例中，住处预订系统使用机器学习预测模型(在本文中被称为可用性模型)预测住处的可用性。

住处预订系统还可以估计假如住处是可用的则客人对于住处的请求将由主人接受的概率。在一个实施例中，住处预订系统使用另一种机器学习预测模型(在本文中被称为接受模型)来基于关于客人的信息、关于旅行的信息和接受或者拒绝住处请求中的主人过去行为，来预测接受的可能性。

本发明的实施例还可以使用可用性模型和接受模型来对响应于搜索查询而返回的列表进行排名。考虑到满足针对住处的用户的请求的住处集合，住处预订系统使用可用性模型和接受模型的输出的功能来将客人最可能能够获得或者预订的所有住处排名更高。其他实施例使用那些模型过滤搜索结果并且仅显示具有大于阈值的可用性概率和/或接受概率的列表。

本发明内容中所描述的特征和优点和以下的详细描述不是穷举的。基于附图、说明书和权利要求书，许多附加特征和优点对于本领域的普通技术人员而言将是明显的。

附图说明

图1是根据本发明的实施例的住处预订系统的系统图。

图2是图示根据本发明的实施例的住处预订系统内的不同模块的框图。

图3是根据本发明的实施例的住处预订系统的类图的示图。

图4是根据本发明的一个实施例的用于更新住处预订系统的日历信息的示例性方法的流程图。

图5是用于在住处预订系统中搜索可用的住处的示例性用户接口。

图6是用于在住处预订系统中查看住处列表的详细的示例性用户接口。

图7是用于在住处预订系统中查看所列出的住处的可用性的示例性用户接口。

图8是用于在住处预订系统中更新所列出的住处的日历信息的示例性用户接口。

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

具体实施方式

系统概述

现在参考图1，示出了适于支持本发明的一个实施例的系统架构。图1和其他附图使用相同的参考标记来标识相同的元件。在诸如“113A”的参考标记之后的字母指示文本特别地是指具有特定参考标记的元件。在没有以下字母的文本中的参考标记(诸如“113”)是指带有参考标记的附图中的任何或者全部元件(例如，文本中的“113”是指附图中的参考标记“113A”和/或“113B”)。

网络105表示客人101、主人103与住处预订系统111之间的通信路径。在一个实施例中，该网络是因特网。网络还可以利用专用或者私有通信链路(例如，WAN、MAN或者LAN)，其不一定是因特网的一部分。网络使用标准通信技术和/或协议。

网络服务器109呈现网页或者其他网络内容，其形成与客人和主人客户端101、103的基本接口。客人和主人使用各自的客户端设备101、103来访问一个或多个网页，并且向住处预订系统111提供数据。在本申请的上下文中，“数据”被理解为包括关于住处的信息、关于旅行、主人、客人等的信息。例如，对于与住处有关的信息而言，数据可以包括诸如价格、房间类型、床型、房间数目、卫生间数目、清洁费、登记时间、退房时间、位置、大小、取消策略、便利设施、房屋规则等的信息。而且，对于关于旅行的信息而言，数据可以包括诸如位置、登记日期、退房日期、客人数目、房间类型偏好、价格范围、期望的便利设施等的信息。

客人是住处预订系统111的一种类型的用户。客人使用客人客户端设备101、基于旅行参数的集合来请求来自住处预订系统111的住处。住处预订系统111然后提供潜在住处的列表，其最好地匹配由客人所提供的旅行参数。

主人是住处预订系统111的另一类型的用户。主人使用主人客户端设备103、基于住处参数的集合来通过住处预订系统111提供住处。住处预订系统111列出住处连同由主人所提供的住处参数。住处预订系统111然后试图将所列出的住处与一个或多个客人匹配，该一个或多个客人可以标识适合于其需要的所列出的住处。

在一个实施例中，客户端设备101、103由客人和主人用于与住处预订系统111交互。客户端设备可以是任何设备，其是或者包含诸如个人计算机(PC)、台式计算机、膝上型计算机、笔记本、智能电话等的计算机。计算机是具有一个或多个通用或者专用处理器、存储器、存储装置和联网部件(有线或者无线)的设备。设备运行操作系统例如兼容MicrosoftWindows的操作系统(OS)、AppleOSX或者iOS、Linux分布程序或者Google的AndroidOS。在一些实施例中，客户端设备101、103可以使用诸如MicrosoftInternetExplorer、MozillaFirefox、GoogleChrome、AppleSafari和/或Opera的网络浏览器113作为与住处预订系统111交互的接口。

住处预订系统111允许主人张贴住处列表并且允许客人搜索和预订住处。住处预订系统111包括以下所描述的附加部件和模块。

住处预订系统

参考图2和图3，在一个实施例中，住处预订系统111包括客人存储库201、主人存储库203、列表存储库205、请求存储库213、预订存储库207、消息存储库209、日历211、预订模块215、搜索模块217、搜索日志219、接受模块221、可用性模块223、日历管理模块225和消息模块227。本领域的技术人员应当理解，住处预订系统111可以包含在本文没有描述的其他模块。另外，未示出诸如防火墙、认证系统、支付处理系统、网络管理工具、负载均衡器等等，这是因为其与本发明无关。可以使用单个计算机、或者计算机网络来实现系统111，包括基于云的计算机实现方案。计算机优选地是服务器类计算机，其包括一个或多个高性能CPU和1G或者更大的主存储器，并且运行诸如LINUX或者其变型的操作系统。可以通过硬件或者通过安装在非瞬态计算机存储中并且由处理器运行以执行如本文所描述的功能的计算机程序，来控制如本文所描述的系统111的操作。使用非瞬态计算机可读存储设备和用于数据访问和检索的适合的数据库管理系统来实现各种存储库(例如，客人存储库201、主人存储库203等)。系统100包括针对本文所描述的操作必要的其他硬件元件，包括网络接口和协议、针对数据条目的输入设备和用于数据的显示、打印或者其他呈现的输出设备。

客人存储库201持久地存储描述在住处预订系统111中请求住处的用户(即客人)的数据，并且是用于执行该功能的一个装置。每个客人由客人对象301表示，其也可以被称为客人简档。关于客人的信息包括诸如姓名、用户名、电子邮件地址、位置、电话号码、性别、出生日期、个人描述、教育、工作、来自其他用户的评论、照片等的个人信息。此外，客人存储库201可以存储诸如客人得分311和有经验的标记315的附加信息。对每个客人分配唯一的ID。客人得分311提供用户作为客人的先前行为的数字表示。在一些实施例中，客人得分基于由来自客人的先前预订的主人所分配的得分。有经验的标记315示出客人是否是住处预订系统111的频繁用户，并且可以例如基于客人已经通过住处预订系统111预订住处的总次数、客人在不久前已经使用住处预订系统111的次数(例如客人在过去60天已经预订的住处的数目)、客人已经使用预订系统111的时间的长度或者其组合。

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

主人得分331提供用户作为主人的先前行为的数字表示。主人得分可以基于由来自主人的先前预订的客人所分配的评级。一般地，预订来自主人的住处的客人每次可以提供主人以及住处的评级。评级然后总计到主人得分中。评级可以根据客人自身的得分311加权，以及基于评级的年代(即，评级几岁)而衰减。

住处预订系统111经由消息模块227使客人和主人能够将消息发送给每个其他相关住处。未决消息333对来自主人尚未响应的客人的消息的数目进行计数(即等待响应的消息的数目)。未决消息333衡量主人对客人的询问的响应性。

过去客人335对主人已经提供住处的客人的数目进行计数。一个实施例对自从主人开始使用住处预订系统111以来主人已经提供住处的客人的总数目进行计数。另一实施例仅考虑主人在最近的过去(例如，在过去的30天内)已经提供住处的客人的数目。

拒绝数目337对主人已经拒绝来自潜在客人的住处请求的次数进行计数。主人可以处于多种原因而拒绝住处请求。例如，如以下所进一步描述的，来自客人的请求可能尚未达到最小天数；或者住处实际上不是可用的，并且主人未更新列表的日历。

时间长度339度量主人已经通过住处预订系统111提供住处的时间量。

主人还可以使用住处预订系统请求来自其他主人的住处，因此变为客人。在这种情况下，该用户将具有客人存储库201和主人存储库203二者中的简档条目。住处预订系统111的实施例可以将客人存储库201和主人存储库203组合到单个用户简档存储库中。如果适用的话，则用户简档存储库然后将存储个人信息以及任何客人相关信息以及主人相关信息。当用户利用住处预订系统提供住处和请求住处时，该方案降低客人存储库201与主人存储库203之间的冗余信息的数量。

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

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

价格353是客人需要支付以便获得所列出的住处的金额。价格353可以被指定为每天、每周和/或每月或者由主人所指定的其他时间段的金额。附加地，价格353可以包括诸如清洁费、宠物费和服务费的附加费用。

单元类型355描述了由主人所提供的住处的类型。实施例将单元类型分类为两个组，房间类型和房产类型。房间的类型包括整个住宅或者公寓、私人房间和共用房间。房产的类型包括公寓、房屋、床位&早餐、小屋、别墅、城堡、宿舍、树上小屋、小船、飞机、停车位、汽车、厢型车、露营车或者休闲车、圆顶建筑、灯塔、圆顶帐篷、帐篷、窑洞、岛、农舍式小屋、地下住居、茅舍、火车、帐棚、阁楼等。

便利设施357列出住处提供的附加特色。便利设施包括允许吸烟、允许宠物、电视、有线电视、因特网、无线因特网、空调、暖气设备、电梯、无障碍设施、游泳池、厨房、房屋的自由停车场、门房、健身房、热水浴缸、室内壁炉、蜂鸣器或者无线对讲机、早餐、适于家庭或者儿童、适于活动、洗衣机、干燥器等。

在一个实施例中，每个列表305与两个类型的日历(主人日历359和所预测的日历359')相关联，其中的每个日历存储关于住处的可用性的信息。主人日历359存储针对如由主人所指定的日期时段中的每个日期的住处的可用性。即，主人访问针对列表的主人日历359，并且手动地指示哪些日期列表是或者不是可用的。主人指定的日历还包括关于住处不可用的日期的信息，因为其已经由客人预订。第二，所预测的日历359'针对日期时段中的每个日期存储住处可用的可能性，如由可用性模块223所确定的。日期时段可以是例如未来的60或者180天。另外，在已经预订住处之后，主人日历359继续存储关于住处实际上预订或者可用的日期的历史信息(例如，针对过去的180天)。

请求存储库213存储由客人做出的住处请求，并且是用于执行该功能的一个装置。每个请求由请求对象307表示。关于请求所存储的信息包括请求日期371、开始日期373、天数375、星期几登记377、星期几退房379、假日381和客人数目383。对每个请求307分配唯一的请求ID。给定请求307与单个客人301和列表305相关联。

请求日期371指定做出请求的日期。开始日期373是请求的客人需要住处的第一天。天数375指定客人需要住处的天数。登记日377和退房日379指定要求登记或者退房的星期几(即，星期一、星期二、星期三等)。该信息不需要由客人提供，因为其可以从开始日期373和天数375被推断出。该信息是重要的，因为一些主人仅允许指定星期几的登记和/或退房(例如仅在工作日或者仅在周末)。假日381指示所请求的住处时段内的假日的日期(如果有的话)。客人数目383规定将停留住处的总人数。

在一些实施例中，可以由与请求307相关联的列表305的主人303接受或者拒绝请求307。此外，如果其未在阈值时间量内由与请求307相关联的列表305的主人303所接受，则请求307也可以终止。在一些实施例中，请求307的终止时间由住处预订系统111设定(例如，如果其在自从提交请求307的时间24小时以来未被接受，则请求307终止)。在其他实施例中，可以由主人303指定请求307的终止时间。在又一实施例中，如果其未在针对其请求住处的日期373之前的阈值时间量被接受，则请求307可以终止(例如，如果其未在开始日期373那天之前的两天被接受，则请求307可以终止)。

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

附加地，住处预订系统可以基于主人和客人对传入消息的响应性，来将得分分配给主人和客人。基于其回复的消息的百分比，可以对每个主人和客人分配响应速率得分。此外，基于用户对传入消息做出响应花费的平均时间，可以对用户分配响应时间得分。

主日历211存储指示列表存储库205中的每个列表的可用性的信息，并且是用于执行该功能的一个装置。每个主人负责更新针对其在住处预订系统111中张贴的每个列表的列表日历359。该信息被用于形成主日历211。在一些实施例中，住处预订系统还包括所预测的日历，其存储住处将可用的概率。在一个实施例中，将日历211和所预测的日历组合到单个日历中，其存储由主人明确地标记为不可用的日期的0的概率和如由主人不可用的不可用的日期的大于0(并且小于或者等于1)的概率。在另一实施例中，负值可以被存储用于由主人明确地标记为不可用的天数。

预订模块215允许客人101预订所提供的住处，并且是用于执行该功能的一个装置。预订模块215更新预订存储库207，并且指示日历管理模块225在主人接受客人的住处请求时，将针对列表的所预订的天数标记为不可用的。预订存储库207存储关于所有预订接受的住处请求的信息。预订存储库207中的每个条目与主人、客人和列表相关联。一旦主人接受客人的对于列表的请求，则条目是由预订模块所做出的预订存储库207。

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

在一些实施例中，搜索模块217基于排名得分对所返回的搜索结果进行排名。排名得分是许多因子的函数，诸如价格、主人评级、离优选位置的距离、列表或者其组合。排名函数可以实现为单个因子的线性组合，其中，每个因子表示为指示匹配度的尺度变量(例如，潜在搜索参数的精确匹配的1，针对部分或者接近匹配的0.5)，并且利用反映因子的重要性的权重进行加权。通常地，对位置和日期高度地加权，并且对便利设施较低地加权，但是特定权重是针对系统管理员的设计决策。在一个实施例中，排名因子包括由可用性模块223和接受模块221所提供的信息。

搜索日志219保持住处预订系统111中所执行的所有搜索查询的记录，并且是用于执行该功能的一个装置。实施例将信息维持在数据库或者其他类型的数据储存库中。每个搜索查询与客人相关联并且包括关于搜索参数的信息和由匹配查询的搜索模块所获得的列表的集合。搜索日志219的一些实施例还存储关于在接收可能的住处的列表之后由客人所采取的动作的信息。例如，搜索日志可以维护关于用户点击或者查看哪些列表和客人请求住处哪些列表的信息。

可用性模块223计算针对给定日期或者日期时段的给定列表的可用性概率(PA)，并且是用于执行该功能的一个装置。可用性模块223的实施例使用机器学习预测模型。在一个实施例中，诸如支持向量机的监督式机器学习算法被用于构建预测模型。在其他实施例中，诸如神经网络、随机森林法或者任何其他监督式学习算法的其他机器学习算法可以被用于建立预测模型。在周期性基础上(例如，一天一次)，可用性模块223计算针对向前的一些天数的每个当前列表305的可用性概率，并且更新列表的所预测的日历359'。例如，假定针对列表305的所预测的日历359'跨越将来的180天，可用性模块223确定每个这样的将来日期列表305将可用的概率，并且将该值存储在针对列表305的所预测的日历359'中。当响应于搜索查询而对列表进行排名时，该所预测的可用性信息可以由搜索模块217用作排名因子。一般地，搜索模块217对具有在所请求的时段期间可用的高概率的列表更高地排名，并且对具有可用的低概率的列表更低地排名。一些实施例仅将由可用性模块所提供的信息用作只在客人请求它时的排名因子。除非由客人另外指定，否则其他实施例在默认情况下使用由可用性模块所提供的信息。在一个实施例中，如果可用性概率低于预订阈值，则住处预订系统111指示住处是不可用的。其他实施例允许用户指定其自身的阈值。下文还描述了可用性模型的构建。

接受模块221计算由特定客人对于主人的特定列表的住处请求的接受概率(PC)，并且是用于执行该功能的一个装置。接受模块221的实施例基于对于主人历史上已经接受和拒绝的列表的请求，使用针对每个主人的接受模型。当客人搜索特定位置中的列表时，接受模块221计算如果给定列表的请求是否由该客人做出，主人将接受该请求的概率。当对搜索结果排名时或者对具有低于阈值得分的接受概率的列表进行过滤时，搜索模块217可以将接受概率用作排名因子。一般地，搜索模块217对具有由主人所接受的高概率的列表更高地排名，并且对具有被接受的低概率的列表更低地排名。

日历管理模块225基于由主人和预订模块215所提供的信息，来更新针对每个列表的日历359，并且是用于执行该功能的一个装置。一些实施例还基于由可用性模块223所提供的信息，来更新针对每个列表的日历。在一个实施例中，日历管理模块225取决于主人更新主人日历359的频率，确定是否基于可用的模块223更新针对列表305的主人日历359。一方面，如果主人103频繁地更新他的日历(例如，更新之间的平均时间量小于阈值)，那么可用于住处预订系统111的信息最可能是最新的。另一方面，如果主人103未频繁地更新他的日历，那么可用于住处预订系统111的信息最可能是过期的，并且可用性模块可以基于主人的可用性历史来估计所列出的住处的真实的可用性。

可用性模型

可用性模块223生成和使用可用性模型来估计在所请求的日期住处可用的概率。在一个实施例中，模块223创建每个主人提供住处的可用性模型。主人特定模型可以对主人的特定行为进行建模，并且在主人具有提供住处的足够的历史的情况下是有用的。在其他实施例中，模块223创建全局或者区域模型以获取地理区域内(例如全国、全州、全市等)的大部分主人的行为。区域模型对于对给定区域内的主人的总体行为而言是有用的，并且反应区域习惯和实践，诸如当本地假日和节日往往使主人或多或少可能具有对客人可用的住处。区域模型对于提供针对关于存在创建主人特定模型所利用的不足的历史信息的主人的默认模型也是有用的。

在一些时间段期间从过去的请求308提取的训练数据的集合上对可用性模型进行训练。时间段可以覆盖所有历史请求或者仅有限的时间段(例如，在过去的六个月)。对于主人特定模型而言，训练集合仅是对于该主人的列表做出的请求308。对于区域模型而言，训练集合是对于区域的地理区域中的所有列表305的请求308(使用每个列表的位置351)。

对于每个列表而言，针对时间段中的特定日期，可用性模型考虑该日期做出的对于住处的所有请求。对于每个请求而言，模型基于请求是否由主人所接受，来确定住处是可用还是不可用的。

对于给定日期的给定请求而言，如果主人接受请求，那么可用性模型确定住处以1的概率是可用的(即住处以0的概率是不可用的)。对于跨越若干天的所接受的请求而言，可用性模块确定包括在请求中的每天以1的概率是可用的。

对于特定日期而言，如果未做出请求，则可用性模型将不具有训练的任何数据或者信息。在这种情况下，可用性模型将不能够提供住处可用的概率的准确的估计。一些实施例在没有请求的情况下分配针对日期的0.5的可用性概率(即住处以0.5的概率是不可用的)。假如主人未将日期明确地标记为不可用的，则其他实施例分配其他概率值。

对于特定日期而言，如果要么拒绝要么终止所有请求，则可用性模块可以计算住处不可用的概率。在一些实施例中，如果拒绝所有请求，则可用性模块分配0的可用性概率。在其他实施例中，阈值数目的请求需要被拒绝以便可用性模型确定针对该日期住处是不可用的。在其他实施例中，基于所拒绝和所终止的请求的数目，确定住处不可用的概率。

在一些实施例中，可用性模块223使用对主人303发送给客人301的消息的响应来训练可用性模型。常常地，在客人301提交针对住处的请求之前，客人301可以将消息发送给主人303以请求关于其列表的更多详细和确认期望的日期是可用的。主人303可以回复指示日期是否可用的消息，并且如果主人303指示任何日期是不可用的，则请求301可能不会提交针对住处的请求。这可以减少可用性模型的训练集合。可以分析由主人303所发送的消息以确定其是否包含所请求的客人301不可用的任何一天的任何指示。在一些实施例中，如果在来自主人303的消息中存在住处不可用的指示，则可用性模块将主人的查询看作所拒绝的请求。

可用性模型的实施例还可以针对周、月和/或假日构建不同天数的模型。例如，可用性模型可以基于星期六的住处的所接受的请求的数目与星期六的住处的所拒绝或者所终止的请求的数目之间的比率，来确定每个星期六具有特定的可用性概率。类似地，可用性模型可以基于往年十二月的一天的所有对于住处的请求，来确定十二月的一天的可用性概率。

实施例还可以基于做出请求的日期对请求住处的日期的接近度，来确定可用性概率。例如，如果提前至少2天做出请求，则主人仅可以提供住处。可用性模型可以基于在请求住处的日期之前“n”天做出的所有先前的请求，来确定住处在将来的“n”天可用的概率。

实施例形成考虑一些或者全部前述准则以预测住处的可用性的模型。不同的准则(即，星期几、月份、提前的天数等)可以被用于确定可以后续通过对其相乘组合的独立概率。在其他实施例中，确定考虑每个准则的单个概率。

在一个实施例中，可用性模块创建作为输入日期的一个或多个特性(例如星期几、月份、是否是假日、当前日期的接近度等)并且生成度量住处将可用的可能性的值的概率函数。例如，可用性模块可以创建计算住处取决于星期几将可用的可能性的概率函数(P(available|day_of_the_week))。可用性模块还可以创建计算住处取决于日期处于哪个月份将可用的可能性的概率函数(P(available|month))。可以针对日期的其他特性创建类似的函数(例如，P(available|holiday)、P(available|proximity_to_current_date)等)。

在可用性模块已经构建可用性模块之后，其可以被用于计算针对将来的某一天的住处的可用性。可用性模块可以计算与给定日期相关联的不同的概率并且将总体概率确定为：

PA＝P(available|day_of_the_week)×P(available|month)×

P(available|holiday)×P(available|proximity_to_date)×…

例如，如果可用性模块将计算针对2014年2月14日的可用性概率，则其可以使用先前分析的历史信息来确定给定列表在该日期期间是否是可用的。例如，2014年2月14日是星期五。根据历史数据，考虑到日期是星期五，可用性模块可以确定什么可用性概率用于该列表。而且，可用性模块可以确定针对2月的一天什么可用性用于该列表。此外，2014年2月14日是情人节。因此，考虑到那天是情人节，可用性模块可以根据历史信息确定列表的可用性是什么。附加地，可用性模块可以基于到2014年2月14日剩余的天数来确定住处的可用性概率。然后，可用性模块可以将那些概率组合并且生成考虑所有先前所提到的因素的总概率。因此，针对住处的可用性概率将是

PA＝P(available|Friday)×P(available|February)×

P(available|Valentine's_day)×P(available|proximity_to_date)

可用性模型有益地使得住处预订系统过滤住处搜索查询的结果或者对相同的结果进行分类。如果将未过滤和/或未分类的搜索结果被呈现给客人，则客人将花费时间查看可用的列表以及不可用的列表。此外，主人可能得到来自请求针对不可用的天数的住处的客人的消息。因此，如果根据可用性对提供给客人的搜索结果进行过滤和/或分类，则对于客人和主人二者将是更有用的并且方便的。

接受模型

接受模块221创建和使用接受模型来估计主人将接受由客人所做出的对于住处的请求的概率。接受模型的实施例以高于阈值的可用性概率对日期做出的过去的请求进行训练。

接受模型的实施例可以考虑关于客人的信息(例如，性别、客人得分311、客人位置313和/或客人经验标记315)；关于主人的信息；关于请求的信息(例如，开始日期373、天数375、登记日期377、退房日期379和/或客人数目383)；关于由客人向主人发送的消息的信息(例如，消息的语言)；关于列表的信息(例如，最大客人数目、拒绝率和/或一致的查询的数目)；和/或关于市场的信息(例如，市场占有率和/或市场需求)。

住处预订系统111可以通过分析特定地理位置中的住处的状态来获得关于市场的信息。例如，为了确定市场占有率，住处预订系统111可以确定针对特定日期所预订的列表305的百分比。附加地，为了确定市场需求，住处预订系统111可以确定已经请求特定时间段中的住处的客人数目301(例如，可以通过对请求2013年2月中的住处的客人数目301进行计数，来确定针对2013年2月的市场需求)。在一个实施例中，通过搜索特定时间段上的具体地理位置中的列表的客人数目301(例如，搜索在2013年2月、在罗马的列表的客人数目301)来确定市场占有率。

实施例形成针对通过住处预订系统111提供住处的每个客人的接受模型。其他实施例形成针对住处预订系统111中的每个列表的接受模型。

在一些实施例中，为了形成针对给定列表的接受模型，接受模块221计算来自在可用日期做出的每个请求的所有训练参数并且确定是否接受或者拒绝请求。在一个实施例中，针对每个训练参数构建概率函数，并且通过将单个概率相乘来计算接受的总概率。

例如，接受模块221可以创建计算主人303将根据客人301的性别而接受对于住处的请求的可能性的概率函数(例如，P(accept|guest_is_mal)e，P(accept|guest_is_female)或者P(accept|guest_gender_is_un))。k接受模n块22o1还可w以创n建主人303将根据其他客人参数而接受请求的概率函数(例如，P(accept|guest_location)、P(accept|guest_score)、P(accept|guest_experience)等)。此外，接受模块221还可以基于请求参数(例如，P(accept|start_date)、P(accept|number_of_days)、P(accept|check_in_day)、P(accept|check_out_day)、P(accept|number_of_guest)等等)、消息参数(例如，P(accept|message_language))、关于列表的信息(例如，P(accept|rate_of_denials)、P(accept|number_of_congruent_inquiries)等)、关于市场的信息(例如，P(accept|market_occupanc)y、P(accept|market_demand))等来创建概率函数。

在接收模块221已经构建接受模型之后，其可以被用于计算主人将接受对于住处的请求的概率。接受模块可以计算与给定请求相关联的不同概率并且将总体概率确定为：

PA＝P(acceptance|gender)×P(acceptance|guest_location)×…×

P(acceptance|start_date)×P(acceptance|number_of_days)×…×

P(acceptance|message_language)×P(acceptance|rate_of_denials)×…×

例如，如果住在美国的男性客人请求在2013年3月15日开始并且在2013年3月17日结束的伦敦的特定住处，则接受模块221可以确定这样的请求将被接受的概率。接受模块可以基于可用的信息来计算单独的概率并且将其组合以估计请求将被接受的总体可能性

PA＝P(acceptance|guest_is_male)×P(acceptance|guest_from_US)×…×

P(acceptance|start:03/15/2013)×P(acceptacne|3_days)×…

在一个实施例中，接受模块221周期性地(例如，每晚)更新接受模型。在一些实施例中，接受模块221仅针对至少阈值时间量已经通过住处预订系统111提供住处的主人(例如，针对已经至少3个月提供住处的主人)或者仅针对具有至少阈值数目的请求的主人(例如，具有通过住处预订系统111的至少50个对于住处的请求的主人)生成接受模型。

接受模块有益地允许住处预订系统111过滤住处搜索查询的结果或者对相同的结果进行分类。例如，住处预订系统111可能已经确定具体主人不接受来自其他国家的主人的对于住处的请求。因此，可以从来自外国的客人的搜索结果过滤掉来自该主人的列表。

评分

在接收到包括地理位置和日期范围的搜索查询时，住处预订系统111计算与搜索查询匹配的住处预订的概率。在一些实施例中，计算住处将可用的概率，并且仅当概率高于阈值时，进一步处理住处。对于与搜索查询匹配的每个住处而言，针对每个所请求的日期，可用性模块223检索住处可用的概率并且通过将针对每个日期的概率相乘来计算总概率。

$PA=\underset{i=1}{\overset{n}{\Π}}P(availablei)$

其中，P(available1)是住处在第一所请求的日期可用的概率，并且P(availablen)是在最后所请求的日期可用的概率。

在可用性模块223已经确定住处将可用的概率高于阈值之后，接受模块221计算与住处相关联的主人将接受对于搜索查询中所指定的日期做出的请求的概率(PC)。然后，住处预订系统可以通过将住处可用的概率和主人将接受请求的概率相乘，来计算客人将能够预订住处的概率(PB)

PB＝PA×PC

在一些实施例中，预订概率(PB)被用于在将搜索结果呈现给客人之前对住处进行排名。在其他实施例中，除了预订概率之外的其他度量(诸如住处的质量得分、主人评级等)可以被用于在将搜索结果呈现给客人之前对住处进行排名。

图4示出了根据本发明的实施例的用于更新住处预订系统的日历信息的过程的流程图。住处预订系统111接收401对于特定地理位置中的列表的请求。基于所接收的请求，住处预订系统111检索403处于所请求的地理位置中的所有列表。针对每个所检索的列表而言，接受模块221根据关于请求客人的列表主人的接受模型来确定405接受概率(PC)。而且，对于每个所检索的列表而言，可用性模块223根据列表主人的可用性模型来确定407可用性概率(PA)。然后，基于可用性概率(PA)和接受概率(PC)，住处预订系统确定预订概率(PB)。最后，基于列表的预订概率(PB)，对列表进行排名411。

图5示出了用于客人录入搜索查询并且查看由搜索模块217所提供的搜索结果的用户接口的示例性实施例。示例性用户接口包括用于客人录入搜索查询的装置。最重要的参数是位置，其在位置文本框501中被录入。实施例仅将位置视为所要求的参数并且将其他参数(诸如登记、退房等)视为可选的。可以在位置文本框501中指定位置。例如，客人已经将位置“SanFrancisco，CA”录入在文本框501中。因此，搜索模块检索靠近SanFrancisco，CA的所有列表。另外，客人已经指定登记日期是文本框503中的2012年9月29日、退房日期是文本框505中的2012年9月30日，并且将仅存在下拉列表507中的1个客人。

搜索模块217基于所指定的参数过滤搜索结果并且显示顶部结果521A至521E。每个所显示的搜索结果包括列表标题523、列表价格525、评论数目527和照片529。可以在下拉列表519中选择用于对搜索结果进行排名和分类的准则。对搜索结果排名和分类的可用的准则包括所推荐的(即住处预订系统基于可用性模型和接受模型来确定哪个是对于客人的最合适的列表)、距离、价格从低到高，价格从高到低，和最新的(即自从已经张贴列表以来的时间量)。

另外，客人可以指定搜索查询中的其他参数，诸如房间类型511、价格范围513、邻近地区515和便利设施517。客人还可以指向地图509中的特定位置以细化所搜索的位置。

图6是用于住处预订系统111中的列表的页面描述的示例性实施例。描述页面包括在搜索结果页面中不可用的附加信息。在描述页面中，客人可以标识房产的照片607的列表、由列表主人所提供的详细描述609、每晚的价格611以及针对整个旅行的总体价格以及列表主人的信息613。

照片607的列表向感兴趣的客人提供所列出的住处的内部、外部和周围看起来如何的想象。在一个实施例中，由列表主人提供照片。在另一实施例中，住处预订系统提供专业摄影师来对所列出的房产的内部、外部和周围进行拍照。

详细描述609提供客人要求的大部分信息以决定所列出的房产是否满足客人的需要。详细描述609包括短距照片、便利设施的列表和房屋规则的列表。在一些实施例中，住处预订系统验证在详细描述中所提供的信息的真实性。其他实施例允许过去的客人经由客人反馈或者评论来验证详细描述的准确度。

价格611对客人示出了单价(即每晚、每周和/或每月的价格)。而且，住处预订系统111至少基于每晚的价格、登记日期、退房日期、客人数目、清洁费、服务费等，来计算住处的总成本。而且，实施例提供“预订它(Bookit)”按钮，其允许客人请求住处并且在客人已经接受请求之后对其进行支付。

主人信息613包括关于列表主人的相关事实。所提供的信息包括响应速率、响应时间和/或日历更新频率。实施例还可以包括主人的照片和/或描述主人的短段落。一些实施例还可以包括“联系我(ContactMe)”按钮，其允许客人与列表主人进行通信。

图7是示出具有住处预订系统111中所列出的住处的可用性的日历的页面的示例性实施例。可以将日历701中的天数标记为可用的、不可用的或者过去的。在一些实施例中，客人仅可以请求标记为可用的日期的住处。在其他实施例中，允许客人请求针对不可用的日期的住处，并且主人可以基于列表的真实可用性来决定是否接受住处请求。

在一些实施例中，在日历中示出了仅预订数目的天数(例如，30天)的可用性。在其他实施例中，住处预订系统允许列表主人决定提前多少天可以做出预订。实施例还允许客人指定针对不同日期的不同价格。例如，客人可以针对周末和假日指定稍高的价格。

图8是用于更新住处预订系统111中所列出的住处的可用性的用户接口的示例性实施例。主人可以将天数标记为不可用的801或者可用的803。接口还可以包括指示最后更新日历的日期的数据字段805和用于主人指示他已经完成更新日历的按钮807。在一个实施例中，主人可以仅指定哪些日期是不可用的，并且所有其他日期由住处预订系统看作潜在地可用的。在其他实施例中，主人需要明确地指示日期是可用的。在一个实施例中，该接口还可以向主人提供关于所计算的可用性概率的信息。

备选的应用

说明书中所描述的特征和优点不是穷举的，并且具体而言，考虑到附图、说明书和权利要求书，许多附加特征和优点对于本领域的普通技术人员而言将是明显的。而且应当注意，说明书中所使用的语言已经主要被选择用于可读性和指导目的，并且可以不被选择为描绘或者限制发明主题。

本发明的实施例的前述描述已经出于图示的目的而被呈现；其不旨在是详尽的或者将本发明限于所公开的精确形式。相关领域的技术人员可以理解，考虑到以上公开内容，许多修改和变型是可能的。

本描述的一些部分描述了根据关于信息的操作的算法和符号表示的本发明的实施例。这些算法描述和表示通常由数据处理领域的技术人员用于将其工作的实质传达给本领域的其他技术人员。虽然功能上、计算上、或者逻辑上进行了描述，但是这些操作被理解为由计算机程序或者等价的电子电路、微码等实现。此外，有时还已经证明方便的是，在没有一般性的损失的情况下，将操作的这些布置指代为模块。可以以软件、固件、硬件或者其任何组合实现所描述的操作和其相关联的模块。

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

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

最后，说明书中所使用的语言已经主要被选择用于可读性和指导目的，并且其可能未被选择为描绘或者限制发明主题。因此，应预期到，本发明的范围不是由该详细描述限制，而是由在基于其的申请上发布的任何权利要求所限制。因此，本发明的实施例的公开内容旨在是对本发明的范围的图示而非限制，在所附的权利要求书中阐述了本发明的范围。

Claims (30)

1.一种计算机实现的方法，包括：

由所述计算机从客人接收针对住处的搜索查询，所述搜索查询包括地理位置和日期范围；

由所述计算机标识所述地理位置中的一个或多个住处；

针对标识的所述一个或多个住处中的每个住处，由所述计算机确定预订概率，其中所述预订概率是对所述客人将能够预订所述搜索查询中所指定的所述日期范围的所述住处的可能性的度量；

至少基于所述预订概率，对标识的所述一个或多个住处进行排名；以及

向所述客人提供经排名的所述住处。

2.根据权利要求1所述的计算机实现的方法，其中所述计算机使用针对可用性概率的预测模型来确定所述预订概率，其中所述可用性概率是对所述住处将可用于所述日期范围的所述可能性的度量。

3.根据权利要求2所述的计算机实现的方法，其中根据对于过去若干天做出的住处的请求，对针对所述可用性概率的所述预测模型进行训练。

4.根据权利要求2所述的计算机实现的方法，其中根据对于过去的至多阈值天数做出的住处的请求，对针对所述可用性概率的所述预测模型进行训练。

5.根据权利要求2所述的计算机实现的方法，其中由所述预测模型确定的所述可用性概率基于请求所述住处是星期几。

6.根据权利要求2所述的计算机实现的方法，其中由所述预测模型确定的所述可用性概率是基于请求所述住处的月份。

7.根据权利要求2所述的计算机实现的方法，其中由所述预测模型确定的所述可用性概率基于请求所述住处的那天是否是假日。

8.根据权利要求1所述的计算机实现的方法，其中所述计算机使用针对接受概率的预测模型来确定所述预订概率，其中所述接受概率是对在假定所述住处是可用的情况下，与所述住处相关联的主人将接受由所述客人做出的请求的所述可能性的度量。

9.根据权利要求8所述的计算机实现的方法，其中根据对于过去若干天做出的请求，对针对所述接受概率的所述预测模型进行训练。

10.根据权利要求8所述的计算机实现的方法，其中根据对于过去若干天做出的、具有大于阈值的可用性概率的请求，对针对所述接受概率的所述预测模型进行训练。

11.根据权利要求8所述的计算机实现的方法，其中通过搜索住处的所述客人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。

12.根据权利要求8所述的计算机实现的方法，其中通过与所述住处相关联的所述主人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。

13.一种住处预订系统，包括：

计算机处理器；

搜索模块，所述搜索模块由所述处理器执行并且被配置为：

从客人接收搜索查询，所述搜索查询包括地理位置和日期范围；

基于所述搜索查询，标识一个或多个住处；

针对标识的所述一个或多个住处中的每个住处，确定预订概率，其中所述预订概率是对所述客人将能够预订所述搜索查询中所指定的所述日期范围的所述住处的可能性的度量；以及

至少基于预订概率，对标识的所述一个或多个住处进行排名。

14.根据权利要求13所述的住处预订系统，还包括：

可用性模块，所述可用性模块由所述计算机执行并且被配置为使用预测模型来确定可用性概率，其中所述可用性概率是对所述住处将可用于所述日期范围的可能性的度量。

15.根据权利要求14所述的住处预订系统，其中根据对于过去的至多阈值天数做出的住处的请求，对针对所述可用性概率的所述预测模型进行训练。

16.根据权利要求14所述的住处预订系统，其中所述可用性概率至少基于选自于由下列各项组成的组中的一项：请求所述住处是星期几、请求所述住处的月份以及请求所述住处的那天是否是假日。

17.根据权利要求13所述的住处预订系统，还包括：

接受模块，所述接受模块由计算机执行并且被配置为使用预测模型来确定接受概率，其中所述接受概率是在假定所述住处是可用的情况下，与所述住处相关联的主人将接受由所述客人做出的请求的可能性的度量。

18.根据权利要求17所述的住处预订系统，其中根据对于过去若干天做出的请求，对针对所述接受概率的所述预测模型进行训练。

19.根据权利要求7所述的住处预订系统，其中对于过去若干天做出的、具有大于阈值的可用性概率的请求，对针对所述接受概率的所述预测模型进行训练。

20.根据权利要求17所述的住处预订系统，其中通过搜索住处的所述客人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。

21.根据权利要求17所述的住处预订系统，其中通过与所述住处相关联的所述主人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。

22.一种包括包含用于预订住处的计算机程序代码的计算机可读存储介质的计算机程序产品，所述计算机程序代码当由处理器执行时引起所述处理器：

从客人接收搜索查询，所述搜索查询包括地理位置和日期范围；

基于所述搜索查询，标识一个或多个住处；

针对标识的所述一个或多个住处中的每个住处，确定预订概率，其中所述预订概率是对所述客人将能够预订所述搜索查询中所指定的所述日期范围的所述住处的可能性的度量；以及

至少基于预订概率，对标识的所述一个或多个住处进行排名。

23.根据权利要求22所述的计算机程序产品，还包括计算机程序代码，所述计算机程序代码引起所述处理器

使用预测模型来确定可用性概率，其中所述可用性概率是对所述住处将可用于所述日期范围的可能性的度量。

24.根据权利要求23所述的计算机程序产品，其中根据对于过去的至多阈值天数做出的住处的请求，对针对所述可用性概率的所述预测模型进行训练。

25.根据权利要求23所述的计算机程序产品，其中所述可用性概率至少基于选自由下列各项组成的组中的一项：请求所述住处是星期几、请求所述住处的月份以及请求所述住处的那天是否是假日。

26.根据权利要求22所述的计算机程序产品，还包括计算机程序代码，所述计算机程序代码引起所述处理器

使用预测模型来确定接受概率，其中所述接受概率是对在假定所述住处是可用的情况下，与所述住处相关联的主人将接受由所述客人做出的请求的可能性的度量。

27.根据权利要求26所述的计算机程序产品，其中根据对于过去若干天做出的请求，对针对所述接受概率的所述预测模型进行训练。

28.根据权利要求26所述的计算机程序产品，其中根据对于过去若干天做出的、具有大于阈值的可用性概率的请求，对针对所述接受概率的所述预测模型进行训练。

29.根据权利要求26所述的计算机程序产品，其中通过搜索住处的所述客人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。

30.根据权利要求26所述的计算机程序产品，其中通过与所述住处相关联的所述主人的一个或多个特性的属性来确定由所述预测模型确定的所述接受概率。