真实世界位置的基于位置的评级

摘要

在线预订系统允许用户创建、搜索和预订货物或服务的列表。当用户搜索列表时，列表至少部分基于包括城市相关性子得分、街区子得分和距离子得分中的至少一项的位置相关性得分被评级。通常，城市相关联子得分量化搜索用户可能实际上在除了搜索查询中规定的城市之外的城市中具有查找列表的意图的可能性。通常，街区相关联子得分量化城市内的具体街区的知名度，作为确定列表的真实世界位置与在搜索查询中规定的位置之间的真实世界距离的距离子得分的替代或辅助。

权利要求

1.一种用于基于与其他用户相关联的历史预订信息向用户提供可用于预订的列表的计算机实现的方法，包括：在浏览会话期间从与用户相关联的客户端设备接收搜索查询，所述搜索查询包括查询城市；

访问可用于由用户预订的多个列表，所述列表中的每个列表位于多个列表城市中的一个列表城市中，所述列表城市中的至少一个列表城市不同于所述查询城市；

访问包括所述查询城市的多个历史搜索查询以及在所述多个列表城市中的多个历史预订，其中所述多个历史搜索查询基于每个用户、每个web浏览会话而被存储和分组；

由计算机处理器基于城市相关性子得分来确定所述列表中的每个列表的位置相关性得分，列表的所述城市相关性子得分指示对于给定的(i)所述搜索查询中包括的城市和(ii)所述列表城市中的历史预订，所述用户将预订所述列表城市中的所述列表的概率；

至少部分基于所述城市相关性子得分对所述列表评级；以及

按照评级顺序向与所述用户相关联的所述客户端设备提供所述列表。

2.根据权利要求1所述的计算机实现的方法，其中所述历史预订包括位于所述列表城市中不同于所述查询城市的列表城市中的至少一个预订。

3.根据权利要求1所述的计算机实现的方法，

其中如果所述查询城市与所述列表城市相同，则列表的所述城市相关性子得分基于第一函数，以及其中如果所述查询城市不同于所述列表城市，则所述城市相关性子得分基于所述第一函数和附加加权因子。

4.根据权利要求1所述的计算机实现的方法，其中所述列表的所述城市相关性子得分基于在与包括所述查询城市的历史搜索查询相同的web浏览会话期间发生的、在所述列表城市中的历史预订的数目。

5.根据权利要求4所述的计算机实现的方法，其中所述列表的所述城市相关性子得分还基于在与包括所述查询城市的历史搜索查询相同的web浏览会话期间发生的历史预订的总数。

6.根据权利要求1所述的计算机实现的方法，其中所述列表的所述城市相关性子得分还基于在所述列表城市中的历史预订的总数。

7.根据权利要求1所述的计算机实现的方法，其中所述列表的所述城市相关性子得分基于所述列表城市中的列表的数目。

8.根据权利要求1所述的计算机实现的方法，其中所述列表的所述城市相关性子得分基于所述列表城市中的列表的数目以及所述多个列表中的列表的总数。

9.一种用于基于与其他用户相关联的历史预订信息向用户提供可用于预订的列表的计算机实现的方法，包括：在浏览会话期间从与用户相关联的客户端设备接收搜索查询，所述搜索查询包括查询城市；

访问可用于由用户预订的多个列表，所述列表中的每个列表位于所述查询城市中的多个列表街区中的一个列表街区中；

访问在所述查询城市中的多个历史预订，其中所述多个历史预定基于每个用户、每个web浏览会话而被存储和分组；

由计算机处理器基于街区相关性子得分来确定所述列表中的每个列表的位置相关性得分，所述街区相关性子得分指示对于给定的(i)所述搜索查询中包括的所述查询城市和(ii)所述查询城市中的所述列表街区中的历史预定，所述用户将预订所述列表街区中的所述列表的概率；

至少部分基于所述街区相关性子得分对所述列表评级；以及

响应于所述搜索查询，按照评级顺序向与所述用户相关联的所述客户端设备提供所述列表。

10.根据权利要求9所述的计算机实现的方法，其中所述历史预订是针对来自所述查询城市中的多个列表街区的列表。

11.根据权利要求9所述的计算机实现的方法，其中所述列表的所述街区相关性子得分基于在所述列表街区中的历史预订的数目。

12.根据权利要求11所述的计算机实现的方法，其中所述列表的所述街区相关性子得分还基于所述列表街区的列表城市中的历史列表的总数。

13.根据权利要求9所述的计算机实现的方法，其中列表的所述街区相关性子得分基于所述列表街区中的可用列表的数目。

14.根据权利要求13所述的计算机实现的方法，其中列表的所述街区相关性子得分还基于所述列表街区的列表城市中的可用列表的总数。

15.根据权利要求9所述的计算机实现的方法，包括：

访问不再可用于由用户预订的多个历史列表，所述历史列表中的每个历史列表位于所述查询城市中的列表街区中的一个列表街区中；以及其中所述列表中的一个列表的所述街区相关性子得分还基于所述历史列表。

说明书

真实世界位置的基于位置的评级

背景技术

[0001] 很多在线计算机系统提供货物和服务的列表用于销售、出租和预约(为了简化，通常称为“预订”)，这些货物和服务的列表具有真实世界位置或者与真实世界位置相关联，真实世界位置具有与其客户无形的值。例如，在给定城市中，某些街区以及甚至特定街道比其他街区和街道更理想。客户将位置作为因素计入其关于是否预订列表的决策中。提供预订的现有的在线计算机系统使用位置对列表进行评级，例如使用给定列表与指定的城市中心或参考点(诸如观光胜地)之间的径向距离作为评级中的一个考虑因素。虽然这些系统所使用的精确的评级机制变化，然而，将严格基于到固定参考点的径向距离的位置合并到评级系统中具有在评级过程中相对于每个其他因素过加权或欠加权预订的位置的风险。

[0002] 在线酒店和餐饮系统提供了合适的示例。通常，列表与用户位置之间的距离是评级列表中的一个因素，并且这些系统通常将列表分类为距用户最近到最远。例如，用户可以决定酒店预约的4英里是合理的行进距离，但是50英里是不合理的。然而，如果两个列表仅相隔1英里，则距离变得不太能够预测预期用户是否会预订一个列表而非另一列表。由于城市通常相隔几英里，所以如果仅有距离，则不能足以作为列表评级中的有用的区分因素。

发明内容

[0003] 在线预订系统允许用户创建货物或服务的列表，搜索由其他用户创建的列表，以及预订他们感兴趣的列表。在线预订系统包括搜索功能，搜索功能响应于搜索查询至少部分基于位置相关性得分对列表评级。列表的位置相关性得分基于列表的位置以及在搜索查询中规定的位置。在各种实施例中，位置相关性得分包括城市相关性子得分、街区子得分和距离子得分中的至少一项。通常，城市相关性子得分量化搜索用户可能实际上在除了搜索查询中规定的城市之外的城市中意图搜索列表的可能性。通常，街区相关联子得分量化城市内的具体街区的知名度，以确定搜索用户在列表的街区中预订的可能性。通常，距离相关性子得分确定列表的位置与在搜索查询中规定的位置之间的距离。

附图说明

[0004] 本发明具有其他优点和特征，这些优点和特征在结合附图时根据本发明的以下详细描述和所附权利要求将更容易清楚，在附图中：

[0005] 图1是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的在线预订系统的计算环境的框图。

[0006] 图2是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的在线预订系统的框图。

[0007] 图3是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的流程图。

具体实施方式

[0008] 系统概述

[0009] 图1是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的在线预订系统的计算环境的框图。图1和其他附图使用相似的附图标记来识别相似的元件。附图标记之后的字母“诸如113A”表示文本具体地指代具有该特定附图标记的元件。文本中没有随后的字母的附图标记“诸如113”指代附图中承载该附图标记的任何或所有元件(例如文本中的“113”指代附图中的附图标记“113A”和/或“113B”)。

[0010] 网络105表示用户103(例如，客户)与在线预订系统111之间的通信路径。在一个实施例中，网络是因特网。网络也可以使用不一定是因特网的一部分的专用或私有通信链路(例如，WAN、MAN或LAN)。网络使用标准通信技术和/或协议。

[0011] 客户端设备101由用户103用于与在线预订系统111通信。客户端设备101可以是作为计算机或包括计算机的任何设备，诸如个人计算机(PC)、台式计算机、膝上型计算机、笔记本、智能电话等。计算机是具有一个或多个通用或专用处理器、存储器、存储装置和连网部件(有线或无线)的设备。设备执行操作系统，例如Microsoft Windows兼容的操作系统(OS)、Apple OS X或iOS、Linux distribution或Google的Android OS。在一些实施例中，客户端设备101可以使用web浏览器113，诸如Microsoft Internet Explorer、Mozilla Firefox、Google Chrome、Apple Safari和/或Opera，作为与在线预订系统111交互的接口。在其他实施例中，客户端设备101可以执行访问在线预订系统111的专用应用。

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

[0013] 在线预订系统111可以是例如酒店预约系统、进餐预约系统、共乘预约系统、零售系统等。更一般地，在线预订系统111向用户提供对可用于客户的资源(例如，货物和服务)的存货清单的访问，并且因此，资源的真实世界物理位置被认为是客户消费(例如，购买、租用或获取)资源的决定中的无形的因素。通常，在一些位置可用的资源比在其他位置可用的相同资源更理想。资源包括酒店、餐饮、车辆、旅游胜地(例如，演出、活动、观光胜地)、购物中心等。例如，在提供酒店的在线预订系统111中，特定街区中的酒店可以或多或少地比在一些街区中的相同的酒店更理想：给定街区可以被认为更有趣、更有名气、更安全、或者具有客户在选择酒店时认为有价值的其他品质。

[0014] 在一些实施例中，在线预订系统111促进用户103之间的交易。例如，酒店预约系统允许用户103预订由酒店预约系统的其他用户提供的酒店。共乘预约系统允许用户103预订从一个位置到另一位置的乘坐。在线市场系统允许用户103与其他用户面对面地购买和/或销售货物或服务。在线预订系统111包括下面描述的另外的部件和模块。

[0015] 在线预订系统概述

[0016] 图2是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的在线预订系统的框图。在线预订系统111包括数据库201、列表模块203、搜索模块205、预订模块207、查看模块209和评级模块211。

[0017] 本领域技术人员应当理解，在线预订系统111包含适合其功能的其他模块(例如，社交网络、银行、商业等)，但是这些模块在本文中没有描述，因为它们不是本发明的直接材料。另外，没有示出传统的元件，诸如防火墙、认证和加密系统、网络管理工具、负载平衡器等，因为它们不是本发明的材料。在线预订系统111可以使用单个计算机或者计算机网络来实现，包括基于云的计算机实现。计算机优选地是包括一个或多个高性能计算机处理器和主存储器并且运行操作系统(诸如，LINUX或其变型)的服务器类计算机。本文中描述的系统111的操作可以通过硬件或者通过计算机程序来控制，计算机程序安装在非瞬态计算机存储装置中并且由处理器执行以执行本文中描述的功能。数据库201使用非瞬态计算机可读存储设备以及用于数据访问和检索的合适的数据库管理系统来实现。数据库201在数据库管理系统中实现，诸如关系数据库(例如，MySQL)。在线预订系统111包括这里描述的操作所需要的其他硬件元件，包括网络接口和协议、用于数据条目的输入设备、以及用于数据的显示、打印或其他呈现的输出设备。下面将会变得清楚的是，在线预订系统111的操作和功能非常复杂足以要求其在计算机系统上实现，并且不能作为人类心智中的实践被执行。

[0018] 列表模块203向用户提供用户接口和处理逻辑以列出用于购买或向其他用户出租的货物或服务，并且是用于进行这一操作的一个手段。例如，如果在线预订系统111是酒店预约系统，则列表模块203提供适合列表酒店的用户界面，诸如房屋、套间、公寓、房间、树屋、城堡、帐篷、躺椅和睡眠空间。如果在线预订系统111是进餐预约系统，则列表模块203提供用于列出酒店、娱乐场所、度假胜地等的可用预约的用户界面。如果在线预订系统是共乘预约系统，则列表模块203提供用于列出可用乘坐的用户界面。

[0019] 列表模块203被配置成从用户接收描述所提供的货物或服务、其可用性的时间帧、价格、位置和其他相关因素的列表。例如，对于酒店预约系统，列表包括酒店的类型(例如，房屋、套间、房间、休息空间等)、其大小的表示(例如，建筑面积或房间数量)、获取或服务可用的日期、以及租金率(例如，每晚、每周、每月等)。列表模块203允许用户包括与货物或服务有关的附加信息，包括照片和其他媒体。列表的位置信息提供对真实世界中的物理位置或区域的具体参考，并且可以包括列表的国家、州、城市和街区、地理坐标、邮寄地址或其他合适的位置说明信息。列表模块203还能够使用外部可用的地图信息来将一种类型的位置信息(例如，邮寄地址)变换成另一类型的位置信息(例如，国家、州、城市和街区)。使用列表用户界面创建的列表由在线预订系统111来处理并且存储在数据库201中。

[0020] 在一些在线预订系统111中，一些列表是暂时的，可用于仅预订一次，和/或能够由列表用户删除。列表模块203将这些历史不可用的列表存储在数据库201中。在线预订系统111使用这些历史列表分析用户在创建、搜索、评级和预订列表时的行为。历史列表可以被加密或保护，使得它们不可用于除了列表系统的操作者之外的其他人。

[0021] 预订模块207向用户提供查看和预订由其他用户创建的列表的用户界面和处理逻辑。预订模块207从预订用户接收支付信息，并且将支付安全地传输给列表用户。作为被处理的购买的一部分而传输的任何用户信息被加密用于用户隐私和保护。在预订完成之后，对预订加密并且将其作为历史预订信息存储在数据库201中。

[0022] 查看模块209提供接收由其他用户提供的列表的查看的用户界面和处理逻辑，以提供评估、反馈和其他与列表有关的评论，并且是用于进行这一操作的一个手段。完成的查看被包括在列表中并且呈现在列表旁边，使得对预订列表感兴趣的未来的用户能够在考虑到查看的情况下来评估列表。查看在数据库201中存储在其相关联的列表旁边。类似于历史列表，历史列表的查看可以在列表不再可用之后继续存储在数据库201中。

[0023] 搜索模块205提供用于响应于搜索请求在数据库中搜索列表的用户界面和处理逻辑，并且是用于进行这一操作的一种手段。搜索模块205的用户界面被配置成接收规定期望货物或服务的各种属性(诸如，类型、位置、价格等)的搜索查询。搜索模块将搜索查询的属性与数据库201中的列表相匹配，使用评级模块211来对列表评级，并且向客户端设备提供评级后的列表的集合，使得客户端设备的用户能够以方便的方式来访问列表。搜索模块205的用户界面能够按照评级顺序显示评级后的列表的集合。

[0024] 取决于实现方式，用于接收搜索查询的用户界面可能很简单，以使得能够输入仅仅单个文本串作为搜索查询，或者可以使得能够在搜索查询中输入多个不同种类的预订的和/或动态的输入选项。用户界面提供位置的说明用于包括在搜索查询中。位置可以自动填充有用户用于执行搜索的客户端设备101A的当前位置。备选地，用户可以在搜索查询中手动输入位置。可以包括国家、州(或另一等同区域，诸如省、地区、版图、行政区、部门、国家、地区或县区)、城市、街区或其他指定，诸如地理坐标(例如，纵坐标、横坐标)、街道地址和邮政编码。

[0025] 评级模块211提供对匹配搜索查询的至少部分的列表进行评级的处理逻辑，并且是用于进行这一操作的一个手段。评级模块211响应于搜索查询从搜索模块205接收列表的集合，对列表进行评级，并且向搜索模块205提供回评级后的列表的集合用于显示。评级模块211根据得分对所接收的列表评级。得分可以基于可以在在线预订系统111的不同实现之间变化的大量不同因素。例如，在酒店预约系统中使用的因素与例如在共乘系统中使用的因素相比可以变化。所使用的特定评分功能取决于整个系统111的属性，并且因此将发生变化。合适的评分功能是能够根据组成因素的组合(例如，线性组合)来构造的任何评分功能，并且每个组成因素可以单独地归一化和/或标准化。评级中的一个因素是位置相关性得分，位置相关性得分基于要评级的列表的真实世界位置和在所接收的搜索查询中规定的真实世界位置。位置相关性得分的确定由下面进一步描述的位置相关性模块213来进行。其他可能的因素包括例如列表的价格、由其他用户提供的列表的查看的次数和质量、列表中的图片的质量、成功和不成功在线预订的数目、答复速率、搜索用户行为信号(如从搜索到列表视图或者从列表视图到预订的点击)、列表是否经由社交网络系统社交路径与搜索者相关联。

[0026] 评级模块211使用存储的历史搜索、预订和列表信息以便对列表评级。为了促进这一操作，搜索205和预订模块207将搜索、列表浏览和预订信息存储在数据库201中。这一历史信息基于每个用户、每个web浏览会话来存储，使得用户与在线预订系统111的交互存储在一起，包括输入的任何搜索查询、查看的任何列表、以及做出的任何预订。将搜索查询和随后的预订存储在一起特别地使得在线预订系统111能够在很多不同的用户上聚集有用的统计数据。例如，基于所存储的历史预订和历史搜索查询，在线预订系统111能够针对给定搜索查询(或其一部分)确定输入该搜索查询的用户做出了何种预订。在线预订系统也可以针对给定预订反向确定用户做出了何种搜索查询。

[0027] 在使用历史搜索、预订和列表信息对列表评级时，评级模块211可以使用任何历史周期。例如，评级模块211可以使用在上一月、在过去的三个月、在过去的6个月、在上一年、一直或者在其之间的任何周期发生的列表、预订和搜索。备选地，评级模块211可以使用来自特定周期的列表、预订和搜索(例如，在特定季节(诸如，冬季)期间发生的，或者在感恩节周末发生的，等等)。

[0028] 在其中本文讨论的系统采集与用户有关的个人信息或者可以利用个人信息的情况下，用户可以被提供控制程序还是特征采集和存储用户信息(例如，是否维持历史列表、历史搜索查询和历史预订)的机会，或者控制是否和/或如何从在线预订系统111接收可能与用户更相关的内容的机会。另外，某些数据可以在存储或使用之前按照一个或多个方式来处理，使得能够去除个人可识别的信息。例如，可以处理用户身份，使得不能确定用户的任何个人可识别信息，或者可以生成获取位置信息的用户的地理位置(诸如，地址、城市或街区)，使得不能确定特定用户位置。因此，用户可以能够控制如何采集与用户有关的信息以及这些信息如何由在线预订系统111来使用。

[0029] 位置相关性

[0030] 位置相关性模块213计算要由评级模块211评级的大量列表中的每个列表的位置相关性得分。给定列表i的位置相关性得分Ri基于城市相关性子得分RCi、街区相关性子得分RNi和距离相关性子得分Di中的至少一项来确定。在可以贡献位置相关性得分Ri的子得分RCi、RNi和Di的确定的单独描述之下来描述位置相关性得分Ri的确定的示例公式。

[0031] 为了确定这些子得分中的每个子得分，位置相关性模块213对来自搜索查询的位置信息进行地理编码。地理编码是识别与位置信息相关联的地理坐标的过程。地理编码根据位置信息生成查询国家QI*、查询城市QC*，并且在一些情况下还生成查询州QS*(或另一区域等同概念)。在此，星号*表示位置相关性模块213当前确定其位置相关性得分Ri的值的当前搜索查询。这区别于来自存储在数据库201中的在确定城市RCi和街区相关性子得分RNi时使用的历史搜索查询和预订的查询国家QI、查询州QS和查询城市QC。

[0032] 城市相关性

[0033] 城市相关性子得分RCi表示城市Ci与输入包括查询城市QC*、查询国家QI*和(有些情况下)查询州QS*的搜索查询的用户的相关性。虽然可以很清楚的是，如果用户输入查询城市QC*，则它们必须对该查询城市特别感兴趣，但不一定是这样。用户通常仅知道主要城市的名称，并且他们不知道在较大城市附近的较小城市。例如，如果查询城市QC*是“圣克鲁兹”，则不一定假定用户意图仅在圣克鲁兹寻找列表。例如，用户可以仅知道“圣克鲁兹”，并且可能不知道这些在附近的城市，诸如阿普托斯和Capitola，它们是流行的旅游胜地。这是一个非常普遍的问题，因为用户通常知道主要城市的名称，诸如曼哈顿、洛杉矶、旧金山等，但是不知道附近的城镇和城市的名称，但是用户实际上频繁地访问这些附近的城镇和城市。这一城市相关性子得分针对关于附近城市的用户信息的这一缺乏通过使用与用户实际上针对特定搜索查询预订哪些城市有关的历史信息来进行调节。在非常广泛的术语中，用户在给定城市A预订得越频繁，在搜索城市B时，城市A与城市B的搜索查询的相关性越大。城市相关性子得分RCi精确地量化这一相关性关系。

[0034] 位置相关性模块213确定一个或多个城市*的城市相关性子得分RCi。对于列表城市Ci中的给定列表i，模块213向列表i分配城市Ci的城市相关性子得分RCi。为了确定城市相关性子得分RCi，位置相关性模块213使用查询国家QI*和(在适当的情况下)查询州Qs*来唯一地识别查询城市QC*，因为世界上很多不同的城市共享相同的名称。例如，密苏里州的斯普林菲尔德和伊利诺斯州的斯普林菲尔德共享相同的城市名称斯普林菲尔德，但是位于不同的州。使用地理编码的查询国家QI*并且在一些情况下查询州Qs*使得能够实现查询城市的唯一识别。

[0035] 位置相关性模块213识别在到查询城市QC*的阈值距离(例如几公里)内的可用列表的集合L。这包括查询城市QC*内的列表，并且还可以包括其他附近城市中的列表，其中一些可以在附近的州和国家。这可以仅包括当前可用的列表，或者其也可以包括不再可用的历史列表。在以下描述中，L还指代这一集合中的列表总数，这根据上下文将很清楚。列表L从数据库201来获得。

[0036] 位置相关性模块213将列表的集合L分为子集，每个城市的一个列表子集LC具有集合L中的列表。在以下描述中，LC还指代每个城市中的列表总数，这根据上下文将很清楚。查询城市QC*的列表的子集是LC*。每个城市Lc和每个集合L中的列表的数目用于归一化城市相关性子得分以避免不适当地朝着大的或小的城市偏离城市相关性子得分RCi。

[0037] 位置相关性模块213还使用查询国家QI*、查询州QS*和查询城市QC*识别来自数据库201的共享相同的QI、QS和QC的历史搜索查询。其中很多历史搜索查询产生在用户输入搜索查询之后、通常在相同的web浏览会话期间发生的历史预订。然而，如以上，这些在线的用户在与其历史搜索查询的查询城市QC相同的城市中结束预订列表不一定是这样。例如，搜索“圣克鲁兹”作为其查询城市的很多用户可能在附近的阿普托斯中结束预订。

[0038] 使用数据库201中的历史预订，模块213识别用户在使用查询城市QC*、查询国家QI*和查询州QS*(在适当的情况下)搜索之后在其中结束预订列表的每个列表城市Ci中的预订总数BQ(Ci)。给定查询城市QC*、查询国家QI*和查询州QS*(在适当的情况下)，来自这些城市的预订也被聚集以确定历史预订的总数BQT。例如，“圣克鲁兹”的搜索可以包括在圣克鲁兹、阿普托斯、Capitola和Soquel的预订。

[0039] 位置相关性模块213使用以上识别的量来得到附加量。模块213识别用户在列表i的城市Ci中预订列表的可能性P(BQ(Ci)|BQT)，假定它们输入包含查询城市QC*、查询国家QI*和查询州QS*(在适当的情况下)的搜索查询。这一量反映历史测量的行为，因为用户在城市B的搜索之后在城市A预订的情况很普遍。这一可能性也可以被计算作为百分比/比率BQ(Ci)/BQT。期望这一量在查询城市QC*匹配列表城市Ci的情况下对于多数列表而言很高。然而，还期望其对于不匹配查询城市QC*的很多其他列表城市而言为非零。

[0040] 位置相关性模块213还相对于在城市Ci发生的历史预订的总数B(Ci)来识别用户在列表i的城市Ci中预订的概率P(Bq(Ci)|B(Ci))。类似地，期望这一量在查询城市QC*匹配列表城市C的情况下对于多数列表而言很高。然而，还期望其对于不匹配查询城市QC*的很多其他列表城市而言为非零。

[0041] 在确定城市相关性子得分RCi时，可以使用第二概率P(Bq(Ci)|B(Ci))来抵消来自先前的段落的第一概率P(BQ(Ci)|BQT)。例如，第一概率P(BQ(Ci)|BQT)量化一个城市(例如，圣克鲁兹、纽约市)的概率人口搜索，但是在另一城市(例如，阿普托斯、纽瓦克)结束预订。不管其与城市的差异(如与纽瓦克相比，阿普托斯更小并且不太被用户知道)，这一概率在很多情况下对于阿普托斯和Neward而言具有可比性。然而第二概率P(Bq(Ci)|B(Ci))可以区分这两种类型的城市。例如，由于阿普托斯是在圣克鲁兹周围的几个小型卫星城市中的一个，所以第二概率P(Bq(Ci)|B(Ci))表示在阿普托斯预订搜索圣克鲁兹的人的数目。更一般地，这表示阿普托斯对在圣克鲁兹搜索预订的信赖。相比较而言，第二概率P(Bq(Ci)|B(Ci))可以通过搜索纽约城开始的在纽瓦克预订的相对较少的人的预订的总计数表示，虽然很多人在纽约城搜索之后在纽瓦克预订(如第一概率P(BQ(Ci)|BQT)给出的)。因此，虽然两个不同城市之间的第一概率可以比得上(在此是阿普托斯和纽瓦克)，然而第二考虑可能不是。因此，将两个概率合并成城市相关性子得分RCi提供用户知识、搜索和预订行为的更加准确的评定。

[0042] 位置相关性模块213使用P(BQ(Ci)|BQT)、P(Bq(Ci)|B(Ci))、LCi和LCi/L中的至少一项来确定城市中的给定列表的城市相关性子得分RCi。在一个一般实施例中，如果查询城市QC*与列表的城市Ci在相同的城市(Qc*＝Ci，LCi＝LC*)，则城市相关性子得分RCi基于P(BQ(Ci)|BQT)和LCi，而如果查询城市QC*与列表的城市Ci不在相同的城市(Qc*≠Ci，LCi≠LC*)，则城市相关性子得分RCi基于以上所有四个值。

[0043] 在一个具体实施例中，城市相关性子得分RCi根据下式来确定：

[0044]

[0045] 其中由下式给出：

[0046]

[0047] 其中f是大于1的数值(例如，如果f＝2，则1/f是均方根操作)，M是归一化得分，使得M＝maxiNi，Wi是由下式给出的附加加权因子：

[0048]

[0049] 通常，以上提及的实施例取决于查询城市QC*是否匹配列表Ci的城市而返回不同RCi的值。如果它们匹配，则列表的Ni值为RCi。如果它们不匹配，则附加加权因子产生从Ni修改的RCi。

[0050] 通常，这一附加加权因子W在不同情况下具有不同影响。加权因子在使用作为另外较大的更加公知的城市的查询城市的搜索之后(例如在与搜索相同的浏览会话期间)频繁地预订的具有列表的较小城市通常更大。使用以上介绍的示例，如果阿普托斯包括在用户搜索圣克鲁兹之后频繁预订的很好地留意的列表，则阿普托斯列表的加权因子相对较大，最终引起RCi较大，从而引起阿普托斯列表与在否则情况下相比在圣克鲁兹的搜索结果中被更高地评级。

[0051] 另一方面，加权因子对于在使用另一查询城市的搜索查询之后没有被频繁预订的较大城市通常较小。例如，如果用户搜索纽约并且他们没有在New Jersey中的城市频繁地结束预订(即使他们刚跨国Hudson River)，然而New Jersey列表的加权因子相对较小，从而引起RCi较低，从而引起New Jersey列表与纽约中的列表相比被很高地评级。

[0052] 街区相关性

[0053] 通常，用户寻找其中位置时他们想要预订列表的地方的类型(例如一般酒店)的唯一表示预订列表。例如，城镇的有趣部分的酒店可能比从高速公路之外的活动隔离的酒店更加理想。街区相关性子得分RNi是量化区分其中用户与列表之间的距离仅不充分的相当的列表的无形价值的一个方式。街区相关性子得分RNi通过使用与哪些街区用户实际上预订有关的历史信息和/或与哪些街区列表位于其中有关的历史信息来量化这些无形价值。在每个广义术语中，如果用户在给定街区相对于其他街区更频繁地预订，则该街区的街区相关性子得分RNi更大。另外，给定街区的列表的数目(或者计数或者相对于其他街区中的列表的数目)可以用作该街区的相关性子得分RNi的归一化因子以避免朝着或者背着具有更大或更小列表的街区的偏置。

[0054] 位置相关性模块213确定查询城市QC*中的一个或多个街区的街区相关性子得分RNi。对于列表街区Ni中的给定列表i，模块213向列表i指派街区Ni的街区相关性子得分RNi。

[0055] 为了确定街区相关性子得分RNi，位置相关性模块213使用查询国家QI*、查询州Qs*和查询城市QC*识别包含列表i的城市LC*中的可用列表的集合。这可以仅包括当前可用的列表，或者也可以包括不再可用的历史列表。在以下描述中，LC还指代这一集合中的列表的总数，这根据上下文很清楚。列表LC从数据库201获得。位置相关性模块213将列表的集合LC分为子集，列表的一个子集LN用于查询城市QC*中的每个街区。在以下描述中，LN还指代每个街区中的列表的总数，这根据上下文很清楚。位置相关性模块213通过访问数据库201中的列表来确定街区LN中的列表的数目以识别每个列表位于其中的街区。这一信息可以由列表用户提供。备选地，街区信息可以由外部源来访问或提供。例如，外因生成的数据库可以提供位置与街区之间的相互关系。

[0056] 位置相关性模块213基于街区Ni中的列表的数目LN、相对于城市Ci中的预订总数BC的预订街区Ni中的列表BN的概率P(BN(Ni)|BC)、以及相对于城市Ci中的列表总数LC的街区Ni中的列表i(由LN(Ni)给出)的概率P(LN(Ni)|LC(Ci))中的至少一项来确定街区相关性子得分RNi。

[0057] 位置相关性模块213通过从数据库201访问历史预订来确定概率P(BN(Ni)|BC(Ci))。模块213单独地针对城市中的每个街区识别每个街区中的列表的历史预订的总数BN、以及所有被包括的街区上的城市中的列表的历史预订的总数BC。概率P(BN(Ni)|BC)也可以计算作为百分比/比率BN(Ni)|BC(Ci)。

[0058] 位置相关性模块213通过从数据库201访问当前可用列表和/或历史列表来确定概率P(LN(Ni)|LC(Ci))。模块213识别城市中的每个街区中的列表的总数LN、以及所有被包括的街区上的城市中的列表的总数LC。概率P(LN(Ni)|LC(Ci))也可以被计算作为百分比/比率LN(Ni)/LC(Ci)。

[0059] 在一个实施例中，位置相关性模块213根据下式来确定街区相关性子得分RNi：

[0060]

[0061] 通常，街区相关性子得分RNi的这一计算对于位于预订相对于相同城市中的其他街区在其中更频繁地发生并且列表相对更普遍出现的街区中的列表产生更高的值。相对于其他街区的给定街区的列表和预订的增加的频率作为该街区对客户的无形价值的程度更高的指示。

[0062] 距离相关性

[0063] 通常，距离相关性子得分Di量化搜索查询的位置与列表的位置之间的距离，使得被评级为更远的列表使用距离的非线性函数被评级为更低。使用非线性函数的原因在于，更大的距离在不舒适或成本方面向用户强加远不止简单的线性增加；换言之，距离期望位置几十英里在不舒适性方面远大于简单地是五英里远的两倍。在一个实施例中，这一距离d从查询城市或街区的中心来确定，通过地理范围或人口密度来确定。在另一实施例中，外部数据源可以提供从其确定距离d的地理位置。在另一实施例中，基于列表i与用户的当前位置之间的距离来测量距离d，例如由客户端设备101(例如，智能电话)来提供。

[0064] 距离相关性子得分Di可以是s型、指数、阶跃、分段线性或者任何其他类型的函数。在一个实施例中，Di根据下式来确定：

[0065]

[0066] 其中d是在查询中规定的位置与b、c之间的距离，d是可配置常数。

[0067] 位置相关性示例

[0068] 在一个实施例中，位置相关性模块213根据下式来确定列表i的位置相关性得分Ri：

[0069]

[0070] 其中城市相关性子得分RCi、街区相关性子得分RNi和距离相关性子得分Di如以上描述地确定。在替选实施例中，除了或者代替这里描述的子得分，可以使用这里没有提及的其他类型的数据来确定位置相关性得分Ri。

[0071] 根据这一函数确定位置相关性得分Ri使得位置相关性得分Ri能够取决于搜索查询和可用于在线预订系统111的数据来变化。取决于搜索查询，历史列表、预订、和/或与由搜索查询指定的国家、州、城市和/或街区有关的查询信息可能不可用于位置相关性模块213。Ri的以上公式使得Ri的计算能够符合信息的变化水平。

[0072] 如果没有城市或街区数据可用，则使用距离相关性子得分Di来确定位置相关性得分Ri。这一情况的基本原理是，如果没有城市或街区数据可用于查询的国家、州和/或城市，则距离是用于确定位置相关性得分Ri的唯一可用类型的数据。

[0073] 如果城市数据可用但是没有街区数据可用，并且查询城市QC*不匹配列表城市Ci，则使用城市相关性子得分RCi而非距离相关性子得分Di来确定位置相关性得分Ri。这一情况的基本原理在于，如果列表在查询城市QC*外部(即与之不相等)，则城市相关性得分RCi与距离相关性子得分相比提供用户预订列表的概率的更加准确的表示。这一情况帮助确保否则由评级模块211很高地评级的列表由于其到查询城市QC*的距离而在评级中没有被低估。

[0074] 如果城市数据可用但是街区数据不可用，并且查询城市QC*匹配列表城市Ci，则使用城市相关性子得分RCi和距离相关性子得分Di来确定位置相关性得分Ri。这一情况的基本原理在于，如果列表在查询城市中，则假定相对于其他城市中的列表的查询城市的位置与列表的位置之间的减小的距离产生相对于其他城市中的列表的用户预订该列表的增加的概率。通过设计，位置相关性得分Ri的这一公式不一定排除在查询城市外部的列表出现在列表的评级集合中，这仅给出位于查询城市的列表的增加。

[0075] 如果城市数据和街区数据可用，并且查询城市QC*匹配列表城市Ci，则使用城市相关性子得分RCi和街区相关性子得分RNi来确定位置相关性得分Ri。这一情况的基本原理在于，假定街区信息与距离数据相比更有可能提供特定列表是否被预订的准确评定。为此，相关性得分的这一公式使用街区相关性子得分RNi取代距离相关性子得分Di。在替选实施例中，在这种情况下，使用所有三个子得分RCi、RNi和Di来确定相关性得分Ri。

[0076] 示例性方法

[0077] 图3是根据一个实施例的使用位置相关性得分对货物或服务的列表评级的流程图。在步骤301，在线预订系统111从客户端设备接收搜索查询，其中搜索查询包括至少查询城市，并且在一些情况下也包括查询州和查询国家。在步骤303，在线预订系统111访问货物或服务的大量存储列表、以及在搜索查询之后发生的历史搜索查询和历史预订。在步骤305，线预订系统111确定每个访问列表的位置相关性得分。列表的位置相关性得分基于城市相关性子得分、街区相关性子得分和距离子得分中的至少一项。在步骤307，线预订系统
111至少部分基于位置相关性得分对列表评级。评级也可以基于其他因素，例如由用户提供的列表的预览的次数、列表的预订的数目、列表的价格等。在步骤309，线预订系统111按照评级顺序向客户端设备提供列表。