CN102902738B

CN102902738B - 使用内联上下文查询的搜索系统及方法

Info

Publication number: CN102902738B
Application number: CN201210337574.9A
Authority: CN
Inventors: 赖纳·克拉夫特
Original assignee: Fly Upward Management Co Ltd
Current assignee: Altaba Inc
Priority date: 2004-07-29
Filing date: 2005-07-21
Publication date: 2016-12-21
Anticipated expiration: 2025-07-21
Also published as: EP1782380A2; US7958115B2; KR20070048761A; JP2008508605A; US20090070326A1; KR101191531B1; WO2006014835A3; US20060026013A1; EP1782380A4; US8655872B2; KR20120015457A; HK1111254A1; CN101124609B; WO2006014835A2; WO2006014835B1; CN101124609A; KR101303488B1; JP4805929B2; CN102902738A

Abstract

本发明提供了一种使用内联上下文查询的搜索系统及方法。与用户在输入查询时正在查看的Web页面或其他文档有关的上下文信息被用于实现搜索。该页面包括上下文搜索界面，该上下文搜索界面具有表示该页面的内容的相关上下文向量。当用户通过上下文搜索界面提交搜索查询时，该查询和上下文向量都被提供给查询处理器并用于响应该查询。

Description

使用内联上下文查询的搜索系统及方法

本申请是国际申请日为2005年7月21日、国际申请号为PCT/US2005/026184，国家申请号为200580032112.4、题为“使用内联上下文查询的搜索系统及方法”的发明专利申请的分案申请。

技术领域

本发明总地涉及一种搜索系统和方法，具体地涉及一种使用内联上下文查询的搜索系统和方法。

背景技术

万维网(World Wide Web，简称Web)，如其名字所暗示的一样，是相互链接的信息的分散性全球集合，该相互链接的信息通常为可以包含虚拟地涉及每个可以想象得到的主题的文本、图像、和/或媒体内容的“页面”形式。知道或查找到页面的统一资源定位器(URL)的用户可以向Web客户程序(通常称为浏览器)提供该URL并可以立即查看该页面。由于网页(Web页)通常都包括到其他页面的链接(也称为“超链接”)，因此，查找URL通常并不困难。

对于大多数用户来说，查找到他们感兴趣的页面的URL比较困难。Web上可获得的内容的数量已经将查找关于特定兴趣的页面的任务变为了可能是最终在大海里捞针的问题。为了解决这个问题，演化出了搜索提供商(例如，Yahoo！、MSN、Google)行业。搜索提供商通常都维护Web页面的数据库，其中，每个页面的URL都与反映其内容的信息(例如，关键字、分类数据等)有关。搜索提供商还维护用于管理Web上的搜索页面(或站点)的搜索服务器。搜索页面具有表格，用户可以将通常包括表示其兴趣的一个或多个项的查询输入该表格中。一旦输入了查询，搜索服务器就访问数据库并生成“命中(hit)”(通常是其内容与从用户的查询中得到的关键字相匹配的页面的URL)列表。该列表被提供给用户。由于查询通常会返回数百、数千、或在一些情况中会返回数百万个命中，所以搜索提供商开发出了用于对这些命中进行排列(即，确定将命中显示给用户的顺序)的复杂算法，以使与给定查询最相关的页面可能出现在该列表的顶部附近。典型的排列算法不仅考虑了关键字及其出现的次数，还考虑了其他信息(诸如，链接到命中页面的其他页面的数量、命中页面在用户中的受欢迎程度等)。

为了进一步方便使用他们的服务，一些搜索提供商现在都提供了用于Web浏览器程序的“搜索工具条”附加软件。搜索工具条通常都具有用户可以在其中键入查询的文本框、以及用于将查询提交给搜索提供商的服务器的“提交(Submit)”按钮。一旦用户安装了搜索工具条，则不管用户正在查看什么页面，搜索工具条通常都是可见的，这使用户能够在任何时候都可以输入查询，而不必首先导航到搜索提供商的Web站。以与在提供商的站点启动的搜索相同的方式来处理通过工具条启动的搜索；唯一的不同在于使用户省去了导航到搜索提供商的站点的步骤。

虽然自动搜索技术非常有用，但其确实还具有很多局限性，最主要的一个是用户需要尽量传送足够多的上下文信息来引导搜索相关内容。太宽的查询(太少的上下文)可能会返回淹没在大量不相关的命中中的很少的几个相关内容；而太窄的查询(太多的上下文)可能会导致相关内容随着不相关内容而被滤掉。通常，用户脑海里有非常具体的上下文，但这种具体的上下文可能没有反映在查询中。例如，输入查询“jaguar(美洲虎)”的用户可能完全正在想的是汽车、动物、专业足球队、或其他事物。

原则上，可以从用户输入查询前所做的事情中收集上下文信息。众所周知，当用户当前正在查阅的信息引发了另外的问题时，通常会促动用户进行搜索。例如，在查看关于汽车的页面后(或同时)输入查询“美洲虎”的用户，极有可能对汽车感兴趣，而在查看关于动物园的页面后(或同时)输入相同查询的用户则极有可能对动物感兴趣。现有的搜索技术没有提供收集这种上下文信息或使用该上下文信息来响应查询的可靠方法。

因此，希望提供一种具有可以用于响应查询的上下文信息的搜索服务器。

发明内容

本发明的实施例提供了一种使用与用户输入查询时正查看的页面或其他文档有关的上下文信息来实现搜索的系统和方法。在一些实施例中，页面或文档包括上下文搜索界面，其中，上下文搜索界面具有表示该页面或文档的内容的有关上下文向量。当用户通过上下文搜索界面提交搜索查询时，上下文向量也被提供给查询处理器并用于对查询进行响应。上下文向量还可以用于其他方面(诸如，选择用户可能感兴趣的其他内容)。

根据本发明的一个方面，提供了一种用于处理查询的方法。通过上下文搜索界面接收用户查询，其中，用户查询包括用户输入的数据。除此之外，接收与上下文搜索界面有关的上下文向量，其中，上下文向量包括表示与上下文搜索界面有关的内容的数据。使用搜索查询和上下文向量对搜索语料库(corpus)进行搜索，以获取包括命中列表的搜索结果。用于呈现的搜索结果被传送给用户。

根据本发明的另一个方面，提供了一种用于向用户提供信息的方法。提供包括内容的页面。使上下文搜索界面与内容相关联，其中，上下文搜索界面用于接收来自用户的查询。使表示内容的上下文向量与上下文搜索界面相关联。通过上下文搜索界面接收来自用户的查询，并将该查询和上下文向量传送给搜索服务器以用于处理，其中，搜索服务器被配置来使用查询和上下文向量对搜索语料库进行搜索，并将搜索结果返回给用户。在一些实施例中，为下文搜索界面限定了未激活状态和激活状态，其中，当处于未激活状态时，上下文搜索界面在页面上显示为小图标，当处于激活状态时，上下文搜索界面在页面上显示为完整界面。例如，可以通过默认以未激活状态显示上下文搜索界面，并可以响应于用户对图标的选择以激活状态重新显示上下文搜索界面。在一些实施例中，响应于用户对图标的选择，可以将特定内容添加到页面中，其中，基于上下文向量来选择该特定内容。

下面的详细描述和附图将提供对本发明的特征和优点的更好的理解。

附图说明

图1是根据本发明实施例的包括客户系统的信息检索和通信网络的高层次框图；

图2是根据本发明实施例的另一个信息检索和通信网络的框图；

图3是根据本发明实施例的具有上下文搜索界面的Web页面的示意图；

图4是根据本发明实施例的用于上下文搜索的上下文向量的示意图；

图5是根据本发明实施例的具有处于未激活状态的上下文搜索界面的Web页面的示意图；

图6是根据本发明实施例的具有多个上下文搜索界面的Web页面的示意图；

图7是根据本发明实施例的由内容开发者执行的用于创建上下文搜索界面的过程的流程图；

图8是根据本发明实施例的用于生成上下文向量的过程的流程图；

图9是根据本发明实施例的用于用户创建上下文搜索界面的过程的流程图；

图10是根据本发明实施例的用于执行上下文搜索的过程的流程图；

图11是根据本发明实施例的用于执行上下文搜索的另一过程的流程图；

图12是根据本发明实施例的具有包括内容的上下文搜索界面的Web页面的示意图；以及

图13是根据本发明实施例的用于选择扩充内容的过程的流程图。

具体实施方式

I.概述

A.网络实现

图1示出了根据本发明实施例的包括客户系统20的信息检索和通信网络10的总体概观。在计算机网络10中，客户系统20通过互联网40或其他通信网络(例如，通过任何局域网(LAN)或广域网(WAN)连接)连接至任意数量的服务器系统501至50N。如本文中将描述的，根据本发明将客户系统20配置为与服务器501至50N中的任意一个进行通信，以(例如)访问、接收、提取、和显示媒体内容和诸如web页面的其他信息。

图1中示出的系统中的多个元件包括不需要在此处详细说明的传统的、公知的元件。例如，客户系统20可以包括桌上型个人计算机、工作站、膝上型电脑、个人数字助理(PDA)、移动电话、任何具有WAP功能的设备(WAP-enabled device)、或能够直接或间接连接至互联网的任何其他计算设备。客户系统20通常运行浏览程序(诸如，微软的InternetExplorer^TM浏览器、Netscape Navigator^TM浏览器、Mozilla^TM浏览器、Opera^TM浏览器、或移动电话、PDA、或其他无线装置中的具有WAP功能的能浏览器(WAP-enabled browser)，等等)，以使客户系统20的用户能够访问、处理、和查看可以通过互联网40从服务器系统501至50N到达客户系统的信息和页面。客户系统20通常还包括诸如键盘、鼠标、触摸屏、笔等的一个或多个用户接口设备22，这些用户接口设备用于与由显示器(例如，监视屏、LCD显示器等)上的由浏览器提供的图形用户界面(GUI)和由服务器系统501至50N或其他服务器提供的页面、表格、和其他信息进行交互。本发明适于与互联网一起使用，其中，互联网指的是特殊的全球网间网。然而，应该理解，除了互联网以外，还可以使用诸如内联网、外联网、虚拟专用网络(VPN)、基于非TCP/IP的网络、任何LAN或WAN等的其他网络或以这些其他网络来代替互联网。

根据一个实施例，客户系统20和其的所有部件都是可以使用包括计算机代码的应用程序进行配置的控制器(operator)，其中，使用诸如IntelPentium^TM处理器、AMD Athlon^TM处理器等中央处理单元或多个处理器来运行所述计算机代码。本文中所述的用于操作和配置客户系统20进行通信、处理、和显示数据和媒体内容的计算机代码优选地被下载并存储到硬盘上，但是全部程序代码、或其多个部分也可以存储在任何其他公知的易失性或非易失性存储介质或设备(诸如，ROM或RAM)中、或设置在能够存储程序代码的任何介质(诸如压缩磁盘(CD)介质、数字多功能磁盘(DVD)介质、软磁盘等)上。此外，全部程序代码、或其多个部分可以从软件源传送并下载，例如，可以通过互联网从服务器系统501至50N之一传送并下载到客户系统20上，或使用任何通信介质和协议(例如，TCP/IP、HTTP、HTTPS、Ethernet、或其他传统介质和协议)通过任何其他网络连接(例如，外联网、VPN、LAN、或其他传统网络)进行传送。

应该理解，用于实现本发明的多个特征的计算机代码可以是C、C++、HTML、XML、Java、JavaScript等代码、或任何其他适合的脚本语言(例如，VBScript)、或可以在客户系统20上执行或经过编译后可以在客户系统20上执行的任何其他合适的编程语言。在一些实施例中，没有代码下载到客户系统20中，而是由服务器执行所需的代码，或执行已经存在于客户系统20中的代码。

B.搜索系统

图2示出了根据本发明实施例的另一个用于传送媒体内容的信息检索和通信网络110。如图所示，网络110包括客户系统120、一个或多个内容服务器系统150、以及搜索服务器系统160。在网络110中，客户系统120通过互联网140或其他通信网络可通信地连接至服务器系统150和160。如上所述，客户系统120及其部件被配置为通过互联网140或其他通信网络与服务器系统150和160以及其他服务器系统进行通信。

1.客户系统

根据一个实施例，在客户系统120上执行的客户应用程序(表示为模块125)包括：指令，其用于控制客户系统120及其部件与服务器系统150和160进行通信、以及处理和显示从服务器系统150和160接收到的数据内容。可以从诸如远程服务器系统(例如，服务器系统150、服务器系统160、或其他远程服务器系统)的软件源将客户应用程序125传送并下载到客户系统120中，或可以将客户应用程序模块125设置在如上所述的客户系统120可读的任何软件存储介质(软磁盘、CD、DVD等)上。例如，一方面，可以通过互联网140将客户应用程序125以HTML包的形式提供给客户系统120，其中，HTML包包括用于在各种对象、帧、和窗口中处理数据和翻译数据的各种控件(例如，嵌入的JavaScript或Active X控件)。

客户应用程序模块125优选地包括用于处理数据和媒体内容的各种软件模块。在一个实施例中，这些模块包括专用搜索模块126、用户界面模块127、和应用程序界面模块128。专用搜索模块126被配置用于处理将要发送给搜索服务器160的搜索请求(本文中也称为查询)和从搜索服务器160接收到的搜索结果数据。下面描述专用搜索模块126的具体特征。

用户界面模块127被配置用于翻译文本和数据帧以及活动窗口(例如，浏览器窗口和对话框)中的数据和媒体内容。在一些实施例中，用户界面模块127包括浏览器程序或与浏览器程序通信，浏览器程序可以是配置在客户系统120上的默认浏览器或其他浏览器。应用程序界面模块128被配置用于支持在客户系统120上执行的客户应用程序125和各种其他应用程序(诸如，电子邮件应用程序、即时通信(IM)应用程序、浏览器应用程序、文件管理应用程序、以及其他应用程序)之间进行连接和通信。

用户界面模块127优选地具有用户输入界面，用户输入界面允许用户输入用于由搜索服务器系统160处理的查询。例如，在用户界面模块127包括浏览器或与浏览器通信的情况下，用户可以输入URL或激活控制按钮，来将浏览器引导至Web搜索页面(或站点)，用户可以通过Web搜索页面(或站点)向搜索服务器系统160提交查询以用于处理。除了用户输入界面之外或代替用户输入界面，用户界面模块127可以包括搜索工具条或其他界面，用户可以通过搜索工具条或其他界面来输入和提交查询，而不必首先导航至搜索页面。在将使用用户界面模块127输入的查询发送至搜索服务器系统160之前，可以通过专用搜索模块126对该查询进行预处理，(例如)以去除所谓的“无用词(stop words)”(“the”、“and”等)、纠正拼写错误等。

根据本发明的实施例，客户应用程序125可以包括用于向用户的查询添加上下文数据(本文中称为“上下文向量”)的各种功能部件(feature)。例如，专用搜索模块126可以被配置来基于输入查询时用户正在查看的内容来生成上下文向量。又例如，在本发明的一些实施例中，显示在浏览器中的Web页面可以包括一个或多个上下文向量，该一个或多个上下文向量可用于补充用户输入的查询。用户界面模块127可以被配置来检测被显示的页面中的这种上下文向量，并使用上下文向量数据来补充用户输入的查询。下面进一步描述这些和其他特征。

2.搜索服务器系统

根据本发明的一个实施例，搜索服务器系统160被配置用于向客户系统120提供搜索结果数据和媒体内容，且搜索服务器系统150被配置来(例如)响应于用户在搜索服务器系统160提供的搜索结果页面中选择的链接，向客户系统120提供诸如Web页面的数据和媒体内容。在一些变化中，搜索服务器系统160返回内容和(或代之以)内容的链接和/或其他参考。

搜索服务器系统160参考随着例如页面、到页面的链接、表示索引页面的内容的数据等而增加的各种页面索引170。可以通过诸如自动Web爬虫172的各种收集技术来生成页面索引；此外，可以提供用于在层级分类结构中的Web页面进行分类和排列的人工或半自动分类算法和接口。这些技术和算法通常可以是传统的设计，并且由于对本发明来说不重要，因此省略了对其详细描述。

在一个实施例中，页面索引170中的条目包括搜索条目、该条目出现的页面的参考(例如，URL或其他经过编码的标识符)、以及页面的上下文标识符。上下文标识符可以用于对在不同上下文中可能有不同含义的搜索条目的相似结果进行分组。例如，搜索条目“美洲虎”可以指英国汽车、动物、专业足球队等。可以使用页面的上下文标识符来表示这些上下文中的哪些是可用的。在一个实施例中，上下文标识符包括页面的类别，其中，该类别是根据内容类别的预定的层级分类指定的。页面参考可以与多个上下文标识符相关联，因此可以在多个上下文中显示相同页面(或其链接)。在一些实施例中，当用户执行各种搜索时，系统自动将上下文标识符与页面链接相关联；还可以通过一组一个或多个索引编辑器来手工地改变标识符以及使其与链接相关联。

搜索服务器系统160被配置用于响应于从客户系统120(特别是从搜索模块126和/或用户界面模块127)接收到的各种搜索请求来提供数据。例如，搜索服务器系统160可以包括查询响应模块164，其中，(例如)可以根据逻辑相关性(可以通过查询中的搜索条目出现的方式来测量)、上下文标识符、页面赞助(page sponsorship)等的组合，通过用于相对于给出的查询对Web页面进行识别和排列的有关搜索的算法来配置该查询响应模块。

根据本发明的实施例，查询响应模块164还被配置用于接收和使用所提供的与查询有关的上下文向量数据，以进一步增强对查询的响应。下面进一步描述响应于查询的上下文向量数据的使用。查询响应模块164还可以利用从赞助内容数据库162获取的附加信息(例如，链接和/或广告副本)来增强搜索结果信息。可以通过每个条目中包含的用于识别赞助页面的参考的附加域、和用于触发赞助内容的显示的关键字，将赞助内容数据库162作为页面索引170的一部分来执行，或可以在单独的数据库中执行该赞助内容数据库。

在一些实施例中，搜索服务器160还包括配置有用于处理接收到的内容的各种算法的上下文处理模块166，以生成表示所接收到的内容的上下文向量的各种算法。通常，上下文向量可以包括表示所有或部分内容的任何数据。例如，用于文本内容的上下文向量的一个实施例可以包括诸如在内容中出现的条目(例如，词或短语)的关键字，且每个这样的条目都可以具有反映该条将在内容中出现了多少次的相关的次数计数。还可以包括其他类型的数据，例如，识别可以包括在内容中的任何链接的URL或其他数据、包括内容的页面的URL或其他标识符、与内容或包括该内容的页面有关的分类数据等。

在一些实施例中，还提供了内容扩充服务器180。内容扩充服务器180经由互联网140与客户应用程序125进行通信，以增强所显示的具有“特定内容”的Web页面的内容，其中，优选地，“特定内容”是根据与所显示的页面有关的上下文向量数据来选择的。在用户已经表示出对有关特定上下文(下面描述其实例)的信息的兴趣的情况中，客户应用程序125向内容扩充服务器180传送上下文向量，内容扩充服务器180通过将要添加至由客户应用程序125显示的Web页面的特定内容做出响应。

在一个实施例中，内容扩充服务器180和搜索服务器160处于集中控制下，内容扩充服务器180优选地从赞助内容数据库162中选择特定内容。在另一个实施例中，内容扩充服务器180可以独立于搜索服务器160并可以拥有其自己的特定内容的数据库(可以基于由用户应用程序125提供的上下文向量从该数据库中做出选择)。

应该理解，本文中所描述的搜索系统是示例性的，可以对其进行改变和修改。内容服务器、搜索服务器、和内容扩充服务器系统可以是一个机构(例如，由Yahoo！公司为用户提供的分布式服务器系统)的部件，或者它们可以是不同机构的部件。每个服务器系统通常都包括至少一个服务器和相关的数据库系统，并可以包括多个服务器和相关的数据库系统，且尽管图中示为单个块，但它们可以是地理上分开的。例如，搜索服务器系统的所有服务器可以位于相互非常靠近的位置(例如，在位于单个建筑或校园中的服务器中心)、或它们可以分布在彼此遥远的位置(例如，位于城市A的一个或多个服务器以及位于城市B的一个或多个服务器)。因此，如本文中所使用的“服务器系统”通常包括一个或多个逻辑上或物理上连接的本地分布的服务器、或横跨一个或多个地理位置分布的服务器；术语“服务器”和“服务器系统”可互换使用。

可以以一个或多个页面索引以及响应于从客户系统接收到的搜索查询而访问一个或多个页面索引并向用户提供搜索结果的算法来配置搜索服务器系统。搜索服务器系统可以自己生成页面索引、从另一个源(例如，分离的服务器系统)接收页面索引、或从另一个源接收页面索引并对其进行进一步的处理(例如，添加或更新上下文标识符)。

C.上下文搜索界面

如上所述，客户应用程序125的用户界面模块127通常包括用于使用户能够向搜索服务器160提交查询(例如，通过将浏览器导航到由搜索服务器160管理的搜索页面或通过提供用于查询提交的工具条界面)的一个或多个界面。这些界面通常可以以传统的方式实现。

根据本发明的实施例，除了这些界面外(或代替这些界面)，用户还可以使用可以作为任意“主”Web页面上的可见元素(element)实现的“上下文搜索”界面来输入上下文查询。(本文中所使用的术语“主Web页面”或“主页面”应被理解为指的是包括至少一个上下文搜索界面的任何页面；主页可以与或可以不与搜索服务器160或内容扩充服务器180处于集中控制下)。每个上下文搜索界面都具有与之有关的上下文向量。不需要在主页面上可见的上下文向量提供反映主页面(或其部分)的内容的附加数据。在如下所述的查询处理过程中，例如查询响应模块164可以使用该数据。

现在将描述上下文搜索界面的实例。图3示出了具有某些内容302的主页面300，其中，当在图2的客户系统120上进行显示时，其可以出现。主页面300包括优选地位于内容302附近的上下文搜索界面304。用户可以通过将查询(例如，“fuel consumption”)输入到界面304的文本域306中并激活“提交”控件308(其可以是例如可点击按钮)来启动上下文搜索。用于主页面300的源代码(未示出)包括与上下文搜索界面304有关的上下文向量。在该实施例中，尽管在请求页面300时向客户应用程序125提供的源代码包括上下文向量的数据，但在页面300中没有实际显示出上下文向量。

可以以各种方式实现的上下文向量优选地包括一个或多个表示相邻内容302的条目和/或分类标签(或任何其他数据)。图4是可以用于由图3的上下文搜索界面304启动的搜索的上下文向量400的实例。上下文向量400包括在内容302中出现的一列条目402(“cabrio”、“golf”等)和与每个条目有关的附加信息。在该实例中，附加信息包括条目出现的次数(term frequency)404、文档频度(document frequency)406、权重408、和条目类型410。条目出现的次数404反映该条目在内容302中出现的次数。文档频度406反映包括该条目的搜索语料库中的文档的数量。权重408反映分配给该条目的重要性，并可以根据诸如该条目出现在文本中还是标题中、条目出现的次数404、和/或文档频度406的信息来计算。条目类型410可以用于区分可能包括在上下文向量中的不同类型的数据(例如，来自文本的条目、分类数据、URL数据等)。应该理解，上下文向量还可以包括更多、更少、或不同于图4中所示的那些元素的元素，且可以以任意所需格式来提供这些元素。在一个实施例中，上下文向量400包括在与用于上下文搜索界面304的代码有关的用于主页面300的源代码中。

当使用客户应用程序125(图2)查看主页面300的用户通过将查询输入到文本域306中并激活提交控件308而启动搜索时，由客户应用程序125发送至搜索服务器160以用于处理的查询优选地不仅包括来自文本域306的显式用户输入，而且还包括上下文向量400的表示。例如，在上下文搜索界面304的一个实现中，Web页面300包括用于响应于提交控件308向搜索服务器160发送HTTP(超文本传输协议)请求的程序代码。该程序代码可以包括用于将用户的查询和上下文向量的表示作为附加数据添加到用于HTTP请求的URL的代码。

除了用户的查询(来自文本域306)和上下文向量400以外，搜索服务器160还可以接收其他元数据，诸如用户的标识符(如果已知)、用户的IP地址、时间等。对于主页面或上下文搜索界面来说，可以是特定的、也可以是不特定的元数据可以从客户应用程序125或其他源获得。

一旦接收到通过上下文搜索界面304启动的查询，搜索服务器160就基于用户的查询和上下文向量(以及可选地任何其他可用的元数据)，使用查询响应模块164来执行搜索。查询响应模块164生成并排列命中列表。将通常至少部分地取决于上下文向量的结果命中列表(例如)以搜索结果页面的形式返回给用户。在执行搜索的过程中，可以以各种方式使用上下文向量。例如，在一个实施例中，可以通过添加从上下文向量中选择的一个或多个关键字来修改用户的查询(例如，图3中的文本域306中的显式输入)；在另一个实施例中，使用所提交的用户的查询和来自用于对结果进行排列的上下文向量的关键字和/或分类数据来执行搜索。下面描述其他实施例。

在一些实施例中，最初可以以“未激活”状态显示主页面的上下文搜索界面，在该状态中，该上下文搜索界面只在页面上出现相对较小的图标。图5中示出了未激活的上下文搜索界面的实例。主页面300′通过与图3的主页面300的源代码相同的源代码生成，并具有相同的内容302。然而，在页面300′中，只显示小的上下文搜索图标504，而不显示图3中所示的完整的上下文搜索界面304。图标504表示未激活的上下文搜索界面；查看页面300′的期望执行关于内容302的上下文搜索的用户，可以(例如)通过点击或以别的方式选择图标504来激活上下文搜索界面。选择图标504，使得具有激活的上下文搜索界面304的图3的页面300被显示，从而用户可以执行上下文搜索。

可以在主页面上设置任意数量的上下文搜索界面，且每个上下文搜索界面都可以具有其自己的反映附近内容的上下文向量。例如，图6示出了主页面600，其内容包括不同新闻报道的多个摘要602、604、606。每个摘要602、604、606都具有位于其附近的各自的上下文搜索图标612、614、616。每个图标612、614、616都是不同的上下文搜索界面的未激活状态，其中的每一个都具有其自己的从相邻摘要602、604、606获得的上下文向量。这些图标中的任何一个都可以由用户激活，然后可以用于启动上下文搜索(例如，以与上述参照图标504和激活的上下文搜索界面304的相同的方式)。用于通过图标612启动的搜索的上下文向量优选地从摘要602获得，而用于通过图标614启动的搜索的上下文向量优选地从摘要604获得，等等。由于图标612和614具有不同的相关上下文向量，所以，即使输入相同的查询，通过图标612和614启动的搜索的搜索结果(命中或它们的排列或两者)通常也是不同的。

在下面进一步描述的一个实施例中，主页面的创建者可以确定将多少个上下文搜索界面包括在它们将位于的页面上、并可以确定应该使用该页面的哪个(些)部分来限定用于搜索的上下文。

下述部分描述上下文搜索界面和上下文向量的创建(第II部分)、处理查询过程中的上下文向量的使用(第III部分)、以及用于进一步提高上下文搜索的其他可选特征(第IV和第V部分)的示例性实施例。

II.上下文搜索界面和上下文向量的创建

A.由内容提供者创建

在一些实施例中，创建Web页面内容的开发者可以随意地将一个或多个上下文搜索界面添加至Web页面。例如，搜索提供商(或上下文搜索技术的其他发布者)可以发布用于实现上下文搜索的应用程序接口(API)。API包括用于指定上下文搜索请求的格式，以使这样的请求可以被搜索服务器160识别和处理。在一个实施例中，API指定用于向搜索服务器160提交上下文搜索的基本URL、以及用于以表示用户查询和上下文向量的附加数据来增强基本URL的格式。API还可以指定用于将查询和/或上下文向量编码为适于特定实现的格式。

在一些实施例中，API还可以指定上下文搜索界面的外观和/或特征。例如，API可以指定界面最初是否应该显示为未激活状态的图标、这样的图标应该是什么样的、以及提醒用户执行上下文搜索的时机的与图标一起显示的标准短语。API的其他特征可以指定激活状态的上下文搜索界面的特征(诸如，是否将提供文本框和/或其他输入域、以及这些域应该是什么样的)。然而，可选地，提供用于上下文搜索的审美方面的统一规范可以帮助提高用户对上下文搜索界面的了解和认识。

可以通过生成可以插入Web页面中的可用图像、或内容创建者可以简单地插入到其页面中的通常使用的Web页面编码语言(诸如HTML)中的适当的代码块，来设置全部或部分API。

内容提供者可以通过在主页面的源代码中包括适当的代码以及以通过用于表示该主页面的实际内容的上下文向量的适当的数据补充该代码，来实现上下文搜索界面。只要该代码的执行可以导致响应于上下文搜索界面的输入而生成与API兼容格式的上下文搜索请求并将其提交至搜索服务器160，就可以使用任何语言中的任何代码。

在其他实施例中，搜索提供商(或上下文搜索技术的其他发布者)例如通过自动生成用于主页面的一些或全部上下文搜索代码来进一步方便内容提供者创建上下文搜索界面。作为一个实例，可以优选地自动从主页面内容生成上下文向量。图7和图8是示出用于创建上下文搜索界面的部分自动过程的流程图，其中，图7示出了由内容开发者执行的过程700，而图8示出了由搜索提供商执行的过程800。

过程700从内容开发者创建或修改用于包括概念搜索界面的Web页面的内容(步骤702)开始。可以使用任何人工或自动技术(包括使用传统的Web开发软件)来创建内容。在某些点上，内容开发者确定希望使上下文搜索界面与主Web页面的内容的某一部分(或全部)相关联。内容开发者选择将与上下文搜索界面相关联的内容(步骤704)并将其提交给搜索提供商(步骤706)。

可以通过多种方式来向搜索提供商提交内容。在一些实施例中，搜索提供商为内容提供者提供基于Web浏览器的上下文分析界面。该界面可以是，例如图2中示出的搜索服务器160的上下文处理模块166的界面。内容开发者可以将其自己的浏览器导航至该界面并输入(例如，通过复制和粘贴)来自主页面的适当内容。在其他实施例中，内容开发者可以将浏览器导航至搜索提供商的上下文分析界面并提交主Web页面的URL。在又一实施例中，搜索提供商可以分发软件工具(例如，结合上下文处理模块166的特点)，内容提供者可以利用该软件工具来选择内容并将其提交给搜索提供商，而无需使用Web浏览器。该工具可以采用诸如可以结合在各种Web内容开发软件程序中的桌面工具或窗口部件的各种形式。

一旦接收到来自开发者的内容，上下文处理模块166就对该内容进行解析并生成上下文向量。图8是可以在上下文处理模块166中实现的过程800的流程图。过程800在上下文处理模块166接收到将与上下文搜索界面相关联的内容时(步骤802)开始。

在步骤804，使接收到的内容标记化(tokenized)。标记化可以通过使用传统的技术来完成并可以包括：(例如)对词边界进行检测、使词规范化(canonicalizing)(例如，去除词尾、纠正拼写错误或变码等)、删去太普通而无助于搜索的各种词(例如，“the”、“and”)，等等。在步骤806，根据适当的标准(诸如，该条目在内容中出现的次数)对标记进行分类，以及在步骤808，选择用于包含在上下文向量中的最频繁出现的标记。可以将所选择的标记的数量限制到(例如)某一整数K。

在步骤810，使用标记创建上下文向量。在一个实施例中，上下文向量包括所选择的标记以及它们的相应次数和其他可选信息。在一些实施例中，还使用标记之间的共现以及相关性来识别也可以包含在上下文向量中的短语。(例如，在图3的内容302中，可以识别短语“Golf Cabrio”)。此外，还可以包括内容中包含的任何链接至文档的URL(或其他标识符)或内容本身的URL(或其他标识符)。一般地说，表示内容或内容的某些方面的任何信息都可以包括在上下文向量中。

在步骤812，将上下文向量插入到用于实现上下文搜索界面的通用代码块中。在一个实施例中，通用代码块包括用于将上下文查询发送至搜索服务器的增强的URL的模板，且步骤812包括将上下文向量(或其编码表示)插入到该模板中。通用代码块还可以包括其他代码(诸如，用于在将用户的查询发送给搜索服务器之前将其插入到增强的URL中的代码、用于以上下文搜索界面的激活和/或未激活状态显示上下文搜索界面的代码等)。在步骤814，将包括上下文向量的结果代码块返回给内容开发者。

再次参照图7，在步骤708，内容开发者从上下文处理模块166接收代码块。在步骤710，内容开发者在期望的点将代码块插入到主Web页面中，从而将上下文搜索界面添加至该页面。

应该理解，本文中描述的用于创建上下文搜索界面的过程是示例性的，可以对其进行改变和修改。可以并列执行按顺序描述的步骤，可以改变步骤的顺序，并可以对步骤进行修改或合并。可以自动或人工执行诸如选择内容和插入上下文搜索代码块的各种步骤。在一个可选实施例中，搜索提供商可以提供能够在内容提供商的系统上安装和运行的上下文处理模块，以使不必为创建上下文向量而向搜索提供者发送信息。此外，在一些实施例中，例如，可以自动创建上下文搜索界面，以在页面内容更新时自动更新上下文向量。例如，在图4的页面400表示头条报道频繁变化的新闻页面的情况下，每当相关的报道改变时，都需要提供用于自动更新上下文搜索界面之一的上下文向量的过程。

还可以实现用于生成上下文向量的其他算法。例如，一些算法可以赋予出现在标题、副标题、元标记(metatags)、或其他所选择的域中的条目高于出现在正文中的条目的权重。一些算法还可以考虑到非文本内容(例如，图像或媒体内容)，对于这些非文本内容，可以使用或确定适当的内容描述信息。上下文向量中的条目不限于单个词；条目还可以是短语(相邻出现的两个或多个词)。在一些实施例中，可以基于不同于在内容中找到的条目的信息来创建上下文向量。例如，可以提示内容提供者指定内容的类别或其他上下文标识符，且可以将该信息包括在上下文向量中。在另一个实施例中，上下文向量可以包括关于包括在内容中的链接的信息(例如，用于链接至页面的链接或分类信息的URL)。

在一些实施例中，可以将上下文向量以编码的形式包括在上下文搜索界面代码块中。例如，可以使用哈希函数(hash function)或其他适当的技术来表示上下文向量中的各种标记。又例如，可以将全部的上下文向量数据存储在搜索服务器可以访问的表格或数据库中，且代码块可以包括在查询处理过程中搜索服务器可以用来查找上下文向量数据的密钥或其他代码。

B.由用户创建

在另一个实施例中，查看任何Web页面的用户都可以创建用于该页面(或用于部分该页面)的上下文搜索界面。例如，搜索提供商可以提供具有“上下文搜索”窗口部件的浏览器工具条，该“上下文搜索”窗口部件可以使用户能够选择显示在浏览器窗口中的任何Web页面的一部分作为用于搜索查询的上下文。

图9是用户创建上下文搜索界面的过程900的流程图。当过程900开始时，用户正在使用浏览器(例如，图2的客户应用程序125的用户界面模块127的显示)查看Web页面。用具有“上下文搜索”窗口部件的工具条配备用户的浏览器。正被查看的页面可以包括或不包括由内容提供者提供的上下文搜索界面。在步骤902，当查看页面时，用户(例如)通过点击从工具条上选择“上下文搜索”按钮。作为响应，在步骤904，浏览器提示用户选择所显示的页面的一部分作为用于搜索的上下文。该提示可以包括(例如)将鼠标光标改变为表示选中的形状、和/或显示文本提示。

在步骤906，用户(例如)通过点击并将鼠标光标拖过所显示的页面的一个区域，来选择所显示的页面的一部分或全部。可以突出显示(例如，改变颜色或在内容周围形成的框)所选择的文本，以向用户提供视觉反馈。在一些实施例中，除了或代替点击和拖拉方法，还可以提供其他的内容选择机制。例如，用户可以通过按下预定的键来选择整个页面、在将鼠标光标置于段落中的任意位置时通过点击来选择该段落、或在将鼠标光标置于节标题中时通过点击来选择该节。

在步骤908，客户应用程序125根据所选择的内容生成上下文向量。在一个实施例中，客户应用程序125可以将所选择的内容提交给用于根据上述的过程800生成上下文向量的搜索服务器160处的上下文处理模块166。在另一个实施例中，客户应用程序125被配置来处理本地内容，以生成上下文向量(例如，通过过程800的步骤)，而不需向搜索服务器传送信息。这种处理能力可以通过例如包括作为图2的客户应用程序125的专用搜索模块126的一部分的上下文处理模块来实现。

在步骤910，浏览器重新显示当前页面，在该页面的所选部分处或附近添加上下文搜索界面。在该实施例中，新添加的上下文搜索界面可以最初以激活状态出现，以使用户可以仅输入并提交查询而不用首先激活界面，新添加的上下文搜索界面也可以最初以未激活状态出现。一旦创建，用户创建的上下文搜索界面就优选地类似于上述上下文搜索界面304来工作；具体地，当用户通过用户创建的上下文搜索界面输入查询时，客户应用程序将该查询以及与用户创建的上下文搜索界面有关的上下文向量提交给搜索服务器。

应该理解，过程900是示例性的，可以对其进行改变和修改。可以并列执行按顺序描述的步骤，可以改变步骤的顺序，并可以对步骤进行修改或合并。例如，用户可以首先选择内容，然后激活搜索工具条中的“上下文搜索”按钮。代替向Web页面添加上下文搜索界面，可以将用户创建的上下文搜索界面置于工具条中(例如，代替标准的非上下文搜索界面)或设置在单独的弹出窗口中。

在另一个实施例中，不是在查询前生成上下文向量，而是客户应用程序可以将所选择的内容与用户的查询一起发送给搜索服务器，搜索服务器可以生成上下文向量(例如，使用上下文处理模块166)作为其查询处理活动的一部分。可以将该上下文向量发送回客户应用程序，客户应用程序可以高速缓存该上下文向量，以用于随后的再次使用。

在另一个实施例中，用户可以(例如)通过选择附随文本的一部分来改善用于预先存在的上下文搜索界面的上下文。在进行这种选择的情况下，可以修改与上下文搜索界面有关的上下文向量，(例如)以包括仅出现在所选择的文本中的条目，从而为用户提供对于如何限定上下文的进一步控制。

在又一个实施例中，客户应用程序还可以包括用于创建可以通过用户的桌面上的或操作系统工具条中的图标来访问的上下文搜索的模块。这种模块可以使用户能够基于不同于Web页面的内容(包括在字处理或文件阅读器应用程序中打开的文档、电子邮件消息、即时消息等)来创建用于执行上下文搜索的上下文向量。不管浏览器是否打开，用户都可以随时激活该图标，并可以从其桌面上的任何文档(包括恰好显示的任何Web页面)中选择用于创建上下文向量的内容。用于所选择内容的用户创建的上下文搜索界面出现在(例如)弹出窗口或位于所选择的内容附近的对话框中、或出现在任何其他适当的用户界面元素中。当执行搜索并返回结果时，客户应用程序优选地打开用于显示该结果并使用户导航到命中的页面或站点的浏览器窗口。

III.查询处理中的上下文向量的使用

如上所述，当激活诸如图3的界面304的上下文搜索界面时，用户可以通过将查询输入到文本域306中并操作提交按钮308来启动上下文搜索。作为响应，通过与上下文搜索界面有关的上下文向量(例如，图4的上下文向量400)来提供可以帮助搜索服务器响应用户查询的上下文信息，并可以自动地将该信息和用户查询一起传送至搜索服务器。

搜索服务器(例如，图2的搜索服务器160)接收包括用户查询和上下文向量的上下文搜索查询，并(例如)使用查询响应模块164执行搜索。用于处理上下文搜索查询的算法优选地使用用户的兴趣可能与相邻内容有关的前提；因此，在生成搜索结果的过程中，优选地使用表示该内容的上下文向量。应该注意，不希望搜索与周围内容相关联的用户可以使用不同的界面(例如，搜索工具条或搜索提供商的Web界面)来执行非上下文搜索，并且搜索服务器160可以被配置来处理上下文和非上下文查询。

现在将描述用于处理上下文搜索查询的具体算法。图10是一个这样的过程1000的流程图，其中，使用来自上下文向量的一个或多个附加条目来补充由用户提供的搜索条目。

在步骤1002，接收包括至少一个用户提供的条目和相关的上下文向量的上下文查询。在步骤1004，(例如)使用传统的查询解析方法从用户提供的条目中提取一个或多个用户关键字，其中，该查询解析方法可以包括：对词边界进行检测、对词进行规范化(例如，去除词尾、纠正拼写错误或变码等)、删去太普通而不能有助于搜索的词(例如，“the”、“and”)等。

在步骤1006，从上下文向量中提取一个或多个关键字，来补充用户关键字。在一些实施例中，上下文向量包括已经被解析和规范(例如，上述的过程800所述)从而已适于用作关键字的条目。在其他实施例中，也可以对上下文向量中的条目进行解析和规范。此外，步骤1006可以包括确定应该将上下文向量中的多少和哪些条目用作上下文关键字。例如，在一些实施例中，可以仅选择具有至少最小次数或权重的条目，可以对可以被选择的条目的数量进行限制，同时可以首先选择具有最大次数或最高权重的条目。还可以基于用户关键字的数量来确定所选择的上下文关键字的数量(例如，对于具有较多用户关键字的查询，可以选择较少的上下文关键字)。步骤1006还可以包括使用用户关键字从查询中检测并去除任何多余的上下文关键字。多余的关键字可以包括精确的复制和已知的同义词。

在步骤1008，使用包括用户关键字和上下文关键字的查询来执行搜索。搜索执行可以包括用于识别包括一个或多个(或者，在一些实施例中，所有的)关键字的Web页面的传统方法；这样的页面在本文中称为“命中”(或“搜索命中”)。在步骤1010，基于由适当的排列算法确定的相关性来对搜索命中进行排列。可以使用基于命中页面中的关键字的次数和/或接近性来对每个命中页面进行记分的传统算法，同时在记分过程中也要考虑用户的关键字和/或上下文关键字。此外，在确定页面分数或排列的过程中，可以使用来自未被选择作为关键字的上下文向量中的任何条目。在确定排列的过程中，还可以考虑包括链接至该命中的页面数量、与命中页面有关的用户评价和偏好、和/或不同命中页面的赞助的其他标准。

在步骤1012，将搜索结果返回给用户。在一个实施例中，将可以通过用户的浏览器显示的具有到不同的命中页面或站点的链接的Web页面作为结果返回。可以通过(例如)将浏览器从主页面重定向至结果页面或通过为结果页面打开新的浏览器窗口来显示结果页面。在将要返回多个命中的情况下，可以生成多个相互链接的结果页面。结果页面可以显示用户的原始查询和添加至搜索查询的上下文关键字。在一些实施例中，使用交互的形式呈现该信息，用户可以通过交互的形式来修改查询或上下文关键字(或两者)并将该经过修改的上下文查询提交给搜索服务器160。

图11是用于执行上下文搜索的可选过程1100的流程图。在过程1100中，使用不具有附加的上下文关键字的用户查询条目来生成命中，并将上下文数据包括在排列算法中。更具体地，在步骤1102，接收包括至少一个用户提供的条目和相关的上下文向量的上下文查询。在步骤1104，从用户提供的条目中提取一个或多个用户关键字；该步骤可以类似于上述的过程1000的步骤1004。在步骤1106，通过使用由用户关键字构成的查询、生成命中列表来执行搜索。与过程1000不同，不使用基于上下文向量的关键字来补充搜索查询中的用户关键字。如对于以上过程1000所述的，可以使用传统的方法来实现搜索执行。

在步骤1108，从上下文向量提取上下文关键字；该步骤可以与上述的过程1000的步骤1006类似。在步骤1110，使用上下文关键字对命中进行排列；在一些实施例中，还可以将用户关键字用于排列。排列算法通常可以类似于过程1000的步骤1010中所使用的算法。在步骤1112，将结果返回给用户，类似于过程1000的步骤1012。与在过程1000中一样，可以使用交互的形式呈现用户的查询和上下文关键字，用户可以通过交互的形式来修改查询或上下文关键字(或两者)并将经过修改的上下文查询提交给搜索服务器160。

应该注意，过程1000和1100可以产生在内容和/或命中顺序方面不同的命中列表。在这些过程中还可以存在其他的变化。例如，可以将来自上下文向量的一些条目用作搜索查询中的上下文关键字，而将其他的条目仅用于对命中进行排列。在其他的变化中，只有上下文关键字可以用于搜索，而仅将用户关键字用于对搜索命中进行排列。

在任何情况下都应该理解，可以使用不同的用于查询的元数据，基于其他的页面排列算法，来进一步修改基于用户关键字和/或上下文关键字的页面排列。实例包括使用用户档案数据(如果用户的身份已知)、以及用于解决含糊条目、推断局部意图(local intent)等的各种试探法。除了命中列表外，搜索结果页面还可以包括由搜索提供商确定的赞助结果或其他内容。

IV.具有扩充的内容的上下文搜索界面

如上所述，上下文搜索界面优选地包括激活或未激活状态。在未激活状态中，可以显示小图标(例如，如图5中所示)；这可以在减少页面上的视觉混乱的同时，仍能够通知用户上下文搜索选项是可用的。在激活状态中，显示查询表格和提交控件(例如，如图3中所示)。

在一些实施例中，当上下文搜索界面为激活状态时，可以以用户可能感兴趣的附加内容(本文中称为“特定内容”)来扩充查询表格。通常，当用户选择激活未激活的上下文搜索图标时，可以推断用户可能对与该上下文有关的内容感兴趣。内容扩充特征使得这样的内容(或到这样的内容的链接)作为激活的上下文搜索界面的一部分来呈现，且不呈现(或隐藏的)未激活的上下文搜索界面。可以基于被激活的上下文搜索界面的上下文向量来动态选择特定内容。

在一个实施例中，扩充的内容包括关于购物的内容(本文中称为“上下文中的商店(Shop in Context)”)，其中，可以为用户提供购买与该内容相关的产品的机会。例如，上述图6的Web页面600包括不同的新闻报道602、604、606的摘要，而这些报道中的每一个都具有其自己的上下文搜索图标612、614、616。用户可以通过点击来激活这些图标中的一个(例如图标612)，从而显示激活的上下文搜索界面并将“上下文中的商店”内容添加至显示的页面中。

图12示出了已经激活了上下文搜索图标612后的Web页面600的一部分。图标612已经扩展为扩充的上下文搜索界面1202，其包括类似于前述上下文搜索界面进行操作的搜索框1204和提交控件1206(在该实例中标记为“search”)。扩充的上下文搜索界面1202还包括“上下文中的商店”内容1208，在该实例中，其提供用于标识人们可以购买与新闻报道602的主题(具体地，关于音乐家Bono)相关的商品的站点的链接和文本。

优选地，基于上下文向量选择用于上下文搜索界面的“上下文中的商店”内容，所以，在同一页面上激活不同的上下文搜索界面通常会产生不同的“上下文中的商店”内容。例如，图12还包括与新闻报道604有关的上下文搜索界面1212；当激活图6的上下文搜索图标616时，将出现界面1212。上下文搜索界面1212包括文本域1214、提交按钮1216、以及“上下文中的商店”内容1218。由于报道604涉及与报道602不同的主题，因此，“上下文中的商店”内容1218(其涉及Venus Williams)不同于内容1208。

在一些实施例中，当用户激活上下文搜索界面时，通过将内容请求从客户应用程序125(图2)发送至内容扩充服务器180来动态生成诸如“上下文中的商店”内容的特定内容。该内容请求包括内容扩充服务器180用来选择适当的特定内容的上下文向量。内容扩充服务器180可以由搜索提供商或其他上下文搜索技术的发布者来操作。

图13是用于生成包括特定内容(例如，“上下文中的商店”内容)的扩充的上下文搜索界面的过程1300的流程图。在步骤1302，在用户浏览器中显示诸如图6的页面600的主页面。如上所述，该主页面包括一个或多个上下文搜索界面，它们中的每一个都处于未激活(图标)状态。在步骤1304，用户(例如)通过点击来激活这些界面中的一个。在步骤1306，将包括用于新激活的界面的上下文向量的内容请求传送至内容扩充服务器180。

在步骤1308，内容扩充服务器180基于上下文向量生成或选择将被添加至主页面的内容。例如，内容扩充服务器180可以访问赞助内容数据库162(图2中所示)，其中，赞助内容数据库162优选地使赞助内容的特定条目与各种关键字相关联。内容扩充服务器180可以从接收到的上下文向量中提取关键字，并基于该关键字从数据库162中选择赞助内容的一个或多个条目。如果需要，可以限制所选条目的数量(例如，在图12中，为每个上下文搜索界面选择两个条目)。在多于与关键字匹配的条目的最大数量的情况下，可以基于不同的标准(例如，每个条目所匹配的关键字的数量或重要性、和/或内容扩充服务器180的提供商和数据库162中的内容的不同赞助者之间的赞助协议的条目的数量或重要性)在这些条目中进行选择。

在步骤1310，内容扩充服务器180将特定内容返回给客户应用程序125，客户应用程序125重新显示包括该特定内容的主页面(步骤1312)。需要时，可以将上下文搜索界面的插入点后的任何主页面内容往下移，以为特定内容腾出空位。

应该理解，本文中描述的过程是示例性的，可以对其进行改变和修改。可以并列执行按顺序描述的步骤，可以改变步骤的顺序，并可以对各步骤进行修改和合并。在一些实施例中，可以预先选择特定内容(例如，当创建或更新上下文搜索界面时)并将该特定内容包括在用于主页面的源代码中，所以不需要对内容扩充服务器进行实时请求。应该理解，在主页面包括多个上下文搜索界面的情况中，可以为任何激活的界面显示特定内容，而还不为任何未激活的界面显示特定内容。

特定内容不限于购物或广告信息。其他类型的特定内容可以包括到关于该内容的新闻报道的链接、到关于该内容的最流行的Web站点的链接、相关的图像或媒体内容、或任何其他类型的内容。例如，可以通过使用上下文向量访问适当的数据库，来基于上下文向量选择任何类型的特定内容。例如，可以通过使用从上下文向量中选择的条目(或所有条目)查询一个或多个新闻服务器或新闻站点来生成到相关新闻报道的链接。例如，可以通过获取最受欢迎的站点的列表并根据包含来自上下文向量的条目的列表来识别站点，而生成最受欢迎的相关站点的列表。通过访问图像数据库可以定位相关图像。

一般地说，可以以各种方式使用与上下文搜索界面有关的上下文向量来识别相关的内容。使用本文中描述的内容扩充系统和方法，可以推迟显示这样的内容，直到用户已经通过激活上下文搜索界面而表示出对这样的内容的兴趣。所以，可以根据用户对主题表达出的兴趣，来得到关于显示在主页面上的特定主题的信息数量。

V.其他实施例

上下文搜索能力和上下文向量具有各种其他实施例和应用。现在将描述一些实例；应该理解，这些实例是示例性的，并不构成对本发明的限制。

在一些实施例中，还可以使用上下文向量来方便用户输入查询。例如，如果用户在查看主Web页面的同时开始向客户应用程序的搜索工具条界面输入查询(例如，通过键入)，则客户应用程序可以使用来自该页面的一个或多个上下文向量来生成用于该查询的自动填充建议。可以完成该工作而不管特定的上下文搜索界面是激活的还是未激活的。例如，如果在图6的页面600，用户将“V-E-N”键入到搜索工具条界面中(图6中未示出)，则客户应用程序可能会建议将“Venus”或“Venus Villiams”作为预期(intended)文本。然后，用户可以敲击Enter或Tab键(或任何其他指定键)来接受该建议或忽略该建议并继续键入。类似地，如果用户开始向上下文搜索界面键入查询，则可以使用用于该界面的上下文向量来为用户生成自动填充建议。

在其他实施例中，可以使用上下文向量来实现“无查询”搜索。从激活的上下文搜索界面(例如，图3的界面304)，用户可以只激活提交按钮，而不用输入任何查询条目。如果提交了不具有用户条目的上下文搜索，则搜索服务器(或客户应用程序)可以配置来基于上下文向量或基于从上下文向量中选择的条目来构造和处理查询。

在一些实施例中，搜索服务器可以收集关于上下文搜索的数据并使用该数据来改善这样的搜索的结果。可以收集例如每个上下文向量或每个主页面的数据。该数据可以包括包含与特定的上下文向量的查询一起接收的或从特定的主页面接收的查询的日志文件、表示输入记录的查询的用户实际调查了哪些命中的点击(clickthrough)统计结果、命中页面的显式用户评价等等。可以以各种方式使用该数据来改善上下文搜索的结果。例如，当查询来自特定的上下文搜索界面时，搜索服务器可以包括伴随着搜索结果的、用户接下来可能要调查的相关查询的一个或多个建议。(例如)可以基于频繁地和相同的上下文向量一起接收的或从相同的主页面接收的其他查询，来确定相关查询。

作为另一个实例，在处理包括相同的上下文向量或源自同一上下文搜索界面的随后的查询的过程中，可以使用与由使用给定的上下文向量或上下文搜索界面的搜索导致的命中相关的点击数据或显式评价数据，来改善搜索命中的分数或排列。例如，具有特定上下文(如由上下文向量表示)的先前的用户频繁访问或高度评价的命中页面或站点较可能对具有相同上下文的随后的用户有用；这样的命中可以使它们的分数或排列向上调整，从而使它们能够得到更为显著的布局。相反，特定上下文中的通常被忽略或具有低用户评价的命中可能不太相关且可能使它们的分数或排列向下调整。

此外，负责上下文搜索界面的内容提供者可以共享关于查询和/或源自特定上下文搜索界面的点击的聚集数据，优选地不对各用户进行识别。内容提供者可以是使用这样的数据来了解访问该站点的用户的兴趣和行为，这可以帮助内容提供者提高站点的有用性和受欢迎程度。

可以将查询和/或点击数据用于内容扩充。例如，当用户激活上下文搜索界面时，特定内容可以包括通过该界面提交的最频繁查询的列表或该界面的之前的用户最频繁访问的站点的列表。可以使用激活的链接来呈现这些查询或站点，以使用户可以通过点击该链接来执行这些查询中的一个或访问站点。

在一些实施例中，搜索服务器(或其他服务器)可以收集关于现有上下文搜索界面的数据，并可以基于它们各自的上下文向量来限定它们之间的关系。例如，可以将具有共同的上下文向量条目的某一部分的两个界面之间的关系限定为“相似”关系；可以将一个界面的上下文向量包括另一个界面的上下文向量的所有条目和至少一个附加条目的情况中的两个界面之间的关系限定为“改进(refinement)”关系。通过这种方式，可以将具有上下文搜索界面的图表限定为节点，并将该关系限定为边缘。在查询处理过程中，可以使用该图表的表示。例如，假设上下文搜索界面A是上下文搜索界面B的改进。当通过界面B提交查询时，可以在处理该查询的过程中使用来自界面A的上下文向量的条目。还可以限定包括间接关系(例如，如果A是B的改进，而B是C的改进，则可以推断A是C的改进)的其他关系，并可以将这些关系用于查询处理中。

在又一个实施例中，可以将上下文搜索查询提交给任何搜索服务器，且可以将不同的上下文搜索提交给由不同实体控制的搜索服务器(例如，通过配置上下文搜索界面来使用于提交查询的URL将他们引导到所需的搜索服务器)。例如，如果创建了有关汽车的上下文搜索界面，并且如果可以在Web上使用用于汽车信息的专用服务器(具有搜索能力)，则可以通过将该服务器的互联网地址包括在URL中来将该上下文搜索路由到该服务器。通过这种方法，上下文搜索可以为用户提供到特别适于它们的上下文的搜索服务器的访问，而用户并不需要预先知道存在这样的服务器。以基于上下文的方式将查询自动引导至适当的服务器的能力可以进一步提高上下文搜索对用户的吸引力。

可以以各种方式来实现上下文查询的选择性路由。例如，在由内容开发者创建上下文搜索界面的情况中，内容开发者可以构造指向Web上的任何服务器的地址的查询URL，并可以通过用于目标服务器的适当格式化的查询来增强URL。这种增强了的URL优选地包括上下文条目(例如，上下文向量)和用户提供的条目。

类似地，在自动生成上下文搜索界面的情况中，生成这种界面的软件可以被配置来基于上下文向量选择用于该查询URL的适当的搜索服务器和格式。应该理解，只要软件模块能够生成将使请求以所选择的搜索服务器能够处理的格式被传送至所选择的搜索服务器的代码，所选择的搜索服务器就不需要具有到界面生成软件模块的创建者或发布者的任何机构上的连接。

在搜索查询将被引导至专用搜索服务器的情况中，上下文搜索界面的激活状态可以包括如上所述的特定内容。该特定内容可以由可以由不同实体控制的专用搜索服务器或内容扩充服务器来提供。该特定内容可以包括关于搜索服务器(搜索将指向的该所搜服务器)的信息(诸如，至搜索服务器的Web站点的链接)。

在又一个实施例中，在执行查询时，做出关于将上下文搜索查询指向何处的决定。例如，可以将所有的上下文搜索查询都指向搜索服务器(例如，图2的搜索服务器160)，该搜索服务器可以基于用户查询和上下文向量信息的结合来确定是否将查询重定向至用于处理的其他服务器。在该实施例中，重定向查询的决定可以部分地取决于用户提供的查询要素。例如，假设用于上下文搜索界面的内容与新唱片集有关。如果用户通过上下文搜索界面输入查询“回顾”，则可以将该查询重定向至音乐回顾数据库，而如果用户通过相同的界面输入查询“购买”，则可以通过搜索服务器来处理该查询，而无需重定向。

在一些实施例中，可以将不同的上下文搜索查询指向相同的搜索服务器(但是，限于搜索语料库的不同部分)。例如，搜索提供商可以将Web页面分割成多个可能的重叠“属性”，诸如“新闻”属性、“购物”属性、“运动”属性，等等。每一个这样的属性都可以作为独立的搜索语料库，并可以基于查询和上下文向量，将搜索指向这些属性中的任何一个或多个。在通过多个属性执行搜索的情况中，还可以将返回特定结果的属性用作对结果进行排列的因素。

其他实施例包括具有用户特有的数据和用于通知搜索结果的上下文的用户个性化特征。例如，搜索提供商可以保存其服务的每个注册用户的用户档案。当登录的注册用户执行搜索(上下文或其他)时，可以记录关于该搜索的信息，并可以将该信息与该用户相关联。通过分析给定的用户查询中的模式，可以开发“用户向量”。在上下文搜索过程中，可以将来自用户向量和上下文向量的信息用于执行搜索和/或对结果进行排列。此外，当用户如上所述激活上下文搜索界面时，用户向量还可以用于动态生成扩充内容。在可以识别输入查询的用户的情况中，可以使用任何的用户特有的信息(例如，用户已经作出书签标记的站点或页面、站点或页面的显式用户评价，等等)和上下文向量一起来通知搜索结果。

在又一个实施例中，用户可以创建用于它们发现有用的上下文搜索界面(或特定的上下文查询)的书签，以使他们容易返回这些界面。应该理解，由于上下文搜索界面返回了取决于上下文(context-dependence)的结果，因此，不是所有的这样的界面都可能对特定的用户都具有相同的有用性。当用户发现一个有用界面时，可以使用传统的基于浏览器的书签或由搜索工具条支持的书签标记(bookmarking)功能来对包含该界面的页面进行书签标记；然而，应该理解的是，如果主页面的内容变化，则上下文向量也变化。因此，本发明的一些实施例使得用户能够(例如)通过保存包括上下文向量的增强的查询URL来对上下文搜索本身进行书签标记。当用户选择该书签时，被提示输入查询，并使用新的查询执行上下文搜索。可选地，用户可以将查询作为书签的一部分来保存，以在以后重新执行特定上下文搜索时选择该书签，而不用考虑主页面的当前内容。

用户还可以(例如)通过各种信任网络机制与其他用户共享他们的进行了书签标记的上下文搜索。在其他实施例中，用户可以对他们的进行了书签标记(或保存了的)的上下文搜索或界面进行注释或标注。

虽然已经参照具体实施例描述了本发明，但本领域的技术人员将会明白，可以对本发明进行多种修改。例如，在本文中提到特定输入设备(例如，计算机鼠标)的情况中，应该理解，可以用不同的输入设备(例如，按键或语音命令)来代替。类似地，本文中提到的可点击按钮和其他图形用户界面控件都可以用任何适当的可选控件来替代。

激活和/或未激活状态的上下文搜索界面的外观也可以不同于本文中示出的外观。例如，激活的界面可以出现在图3所示的主页面中或出现在单独的弹出窗口中。此外，可以改变图标和/或激活的界面元素的外观。这种改变可以由上下文搜索发布者或内容提供者来控制。仅作为一个实例，可以通过改变未激活的图标的外观来暗示上下文；所以，可以将胶片夹包括在用于与娱乐相关的搜索的图标中、可以将足球或棒球包括在用于与运动相关的搜索的图标中，等等。可以将一致的文本串(例如，如图6中所示的“Search This”)或其他要素包括在图标中，作为该图标表示上下文搜索界面的进一步表示。

在另一个变化中，可以以隐藏和可见模式来实现上下文搜索图标的未激活状态。例如，除了在用户的鼠标光标定位在或移动通过相关内容时以外，可以隐藏上下文搜索图标(即，不在主页面上显示)。当如此定位鼠标光标时，该图标变为可见的，用户可以通过点击来激活它。例如，可以使用诸如Java的语言来实现隐藏和可见模式。

本文中描述的实施例可以参照Web站点页面、链接、以及用作搜索语料库的万维网(或其子集)的实例特有的其他术语。应该理解，本文中描述的系统和过程适于使用不同的搜索语料库(诸如电子数据库或文档储存库)且结果可以包括内容以及链接或参考可以发现内容的位置。

此外，已经参照具有特定硬件和软件元件的计算机系统描述了本发明。应该理解，还可以实现具有硬件和/或软件元件的其他结合的其他系统。

因此，尽管已经参照具体实施例描述了本发明，但应该理解，本发明旨在覆盖所附权利要求的范围中的所有修改及其等同物。

Claims

1.一种搜索方法，包括：

接收来自用户的搜索请求；

响应于所述搜索请求，基于第一内容生成上下文向量；

其中，在所述搜索请求被接收时，所述第一内容在客户端处被显示；

其中，所述上下文向量包括未被所述用户输入的一个或多个条目；

执行或使得所述客户端执行以下步骤：

向服务器发送所述上下文向量；

响应于向所述服务器发送所述上下文向量，接收来自所述服务器的搜索结果；

其中，所述搜索结果至少基于所述上下文向量；

显示所述搜索结果。

2.根据权利要求1所述的方法，其中，所述方法通过工具条、窗口部件或操作系统模块中的一种来执行。

3.根据权利要求1所述的方法，其中，所述客户端包括web浏览器、字处理应用、文件阅读器应用、电子邮件应用或即时消息应用中的一种。

4.根据权利要求1所述的方法，还包括在web浏览器中显示所述搜索结果。

5.根据权利要求1所述的方法，其中，所述方法由web浏览器执行。

6.根据权利要求1所述的方法，还包括基于在所述搜索请求时被选择的第一内容来识别第一内容。

7.根据权利要求1所述的方法，

其中，所述搜索请求是包括用户输入的查询数据的用户查询；

其中，所述方法还包括执行或者使得所述客户端执行将所述用户查询与所述上下文向量一起发送到服务器的步骤；

其中，所述搜索结果至少基于所述用户查询和所述上下文向量。

8.根据权利要求1所述的方法，其中，接收所述搜索请求包括接收在由所述客户端显示的网页中选择所述第一内容的用户输入，其中，所述第一内容不包括整个网页。

9.根据权利要求1所述的方法，

其中，接收所述搜索请求包括：

接收在由所述客户端显示的页面中选择第一内容的用户输入，其中，所述第一内容不包括整个页面；

响应于所述用户输入，向所述用户呈现与所述第一内容相关联的上下文搜索界面；

接收指示所述用户已经在所述上下文界面中选择了控制的输入；

其中，所述方法还包括：

响应于用户在所述上下文界面中选择了控制，向搜索引擎提交查询，其中，所述查询至少包括所述上下文向量。

10.根据权利要求9所述的方法，

其中，接收所述搜索请求还包括经由所述上下文搜索界面接收包括用户输入的查询数据的用户查询，

11.根据权利要求1所述的方法，其中，所述上下文向量包括表示所有或部分所述第一内容的数据。

12.根据权利要求1所述的方法，其中，生成所述上下文向量包括将所述第一内容发送到服务器处的上下文处理模块，以及接收作为响应的上下文向量。

13.一种搜索方法，包括：

向客户端发送内容页面，所述内容页面包括当由所述客户端编译时使得所述客户端执行以下处理的指令：

至少显示第一内容，其中所述第一内容是所述内容页面中的内容的子集；

显示一个或多个上下文搜索图标；

其中，作为编译所述内容页面的结果而显示的每个上下文搜索图标分别与所述内容页面的内容的不同部分相关联；

其中，所述上下文搜索图标包括与所述第一内容相关联的具体上下文搜索图标；

检测对所述具体上下文搜索图标的用户选择；

响应于检测到所述用户选择，在继续显示所述内容页面的至少一部分的同时，显示与所述具体上下文搜索图标相对应的扩展的上下文搜索界面，所述扩展的上下文搜索界面包括以下两者：(a)被配置用于接收来自所述用户的一个或多个查询条目的输入的查询输入域，和(b)搜索提交控制元素。

14.根据权利要求13所述的方法，其中，在检测到对所述具体上下文搜索图标的所述用户选择之前，不显示所述扩展的上下文搜索界面。

15.根据权利要求13所述的方法，其中，显示所述扩展的上下文搜索界面包括将所述查询输入域显示为所述内容页面的元素。

16.根据权利要求13所述的方法，其中，显示所述扩展的上下文搜索界面包括显示包含所述查询输入域的弹出元素。

17.根据权利要求13所述的方法，其中，所述内容页面中的指令还被配置为使得所述客户端执行：在选择了所述搜索提交控制元素后，向服务器提交包括所述一个或多个查询条目以及代表所述第一内容的数据的搜索请求。

18.根据权利要求17所述的方法，其中，所述内容页面中的指令还被配置为使得所述客户端执行：

接收响应于所述搜索请求的搜索结果；

在所述扩展的上下文搜索界面中显示所述搜索结果，同时继续显示所述内容页面的至少一部分。

19.根据权利要求17所述的方法，其中，代表所述第一内容的所述数据是所述第一内容或者从所述第一内容获得的上下文向量中的一种。

20.根据权利要求17所述的方法，其中，代表所述第一内容的所述数据是上下文向量，所述上下文向量包含从所述第一内容提取的一个或多个条目。

21.根据权利要求13所述的方法，其中，所述内容页面中的指令还被配置为使得所述客户端执行：

在所述用户提交任何查询数据之前，向服务器发送包括代表所述第一内容的数据的搜索请求；

在所述用户提交任何查询数据之前，响应于向所述服务器发送所述搜索请求，从所述服务器接收基于使用代表所述第一内容的所述数据进行的搜索而生成的命中的列表，用于与所述扩展的上下文搜索界面一起显示；以及

在继续显示所述内容页面的至少一部分的同时，在所述用户提交任何查询数据之前，在所述扩展的上下文搜索界面中或在所述扩展的上下文搜索界面附近显示所述命中的列表。

22.根据权利要求21所述的方法，其中，代表所述第一内容的所述数据是所述第一内容或者从所述第一内容获得的上下文向量中的一种。

23.根据权利要求21所述的方法，其中，代表所述第一内容的所述数据是上下文向量，所述上下文向量包含从所述第一内容提取的一个或多个条目。

24.根据权利要求21所述的方法，其中，所述内容页面中的指令还被配置为使得所述客户端执行：在用户选择了所述搜索提交控制元素后，向服务器提交包括所述一个或多个查询条目以及代表所述第一内容的数据的搜索请求。

25.根据权利要求13所述的方法，其中，所述指令被配置为通过至少部分地从服务器获取代码块并执行所述代码块中的代码，使得所述客户端显示所述一个或多个上下文搜索图标以及显示所述扩展的上下文搜索界面。

26.根据权利要求13所述的方法，其中，所述指令当被所述客户端编译时还使得经由来自服务器的应用程序接口API生成所述扩展的上下文搜索界面。

27.根据权利要求13所述的方法，其中，所述内容页面中的内容包括超文本标记语言HTML内容，其中，所述指令包括插入到所述HTML内容中的JavaScript代码。

28.根据权利要求13所述的方法，还包括：

在所述内容页面中具有所述指令之前，基于对所述内容页面的分析来识别不同的部分；

对于每个不同的部分：

标记所述内容的部分以生成标记；

基于所述标记生成上下文向量；以及

向所述指令添加用于基于所述上下文向量生成上下文搜索界面的代码块；

将所述指令插入到所述内容页面中；

其中，所述扩展的上下文搜索界面被配置为将具体上下文向量与所述一个或多个查询条目一起提交给搜索服务器。

29.一种搜索系统，包括被耦合到网络的一个或多个计算设备上的一个或多个处理器，所述一个或多个处理器被配置为执行权利要求1-28中任何一个所述的搜索方法。