KR20060006913A

KR20060006913A - 서브도메인 힌트를 포함하는 검색 결과를 생성하고서브도메인에 의해 스폰서되는 결과를 제공하는 시스템

Info

Publication number: KR20060006913A
Application number: KR1020057018923A
Authority: KR
Inventors: 알리 다이압; 스콧 에이. 가츠; 샴 카퍼; 데이빗 쿠; 척 쿵; 푸 호앙; 키 루; 린느 포그; 유안 퀴 쉔; 노먼 쉬; 타이 트란; 에카르트 발터; 제프 웨이너
Original assignee: 야후! 인크.
Priority date: 2003-04-04
Filing date: 2004-04-05
Publication date: 2006-01-20
Also published as: US20150012559A1; US9262530B2; US9323848B2; WO2004090754A1; US20150112959A1; US20090157642A1; US8849796B2; US7499914B2; JP5813155B2; CN1784681A; JP2012230693A; JP5607115B2; US8271480B2; EP1611534A1; JP2014160476A; US20160239503A1; US20050228780A1; KR101123426B1; JP5068996B2; EP2672403A1

Abstract

본 발명은 서브도메인(132)에 의한 검색을 포함하는 검색 결과를 생성하고 서브도메인(132)에 의해 스폰서되는 결과를 제공하는 방법 및 장치를 제공한다. 본 발명의 실시예에 따르는 검색 시스템(100)은 검색 질의(110)를 분석하여 그들이 서브도메인(130)에 경로 설정되어 있는지를 결정하고, 서브도메인별로 기초로 하여 스폰서되는 스폰서 히트를 포함하는 결과를 제공한다.

Description

서브도메인 힌트를 포함하는 검색 결과를 생성하고 서브도메인에 의해 스폰서되는 결과를 제공하는 시스템{A SYSTEM FOR GENERATING SEARCH RESULTS INCLUDING SEARCHING BY SUBDOMAIN HINTS AND PROVIDING SPONSORED RESULTS BY SUBDOMAIN}

본 발명은 일반적으로 콘텐츠 검색에 관한 것으로, 특히 검색 요청에 응답하여 콘텐츠를 검색하는 방법 및 장치에 관한 것이다.

관련출원

본 출원은 2003년 4월 4일자로 출원된 "Search System Using Search Subdomain and Hints to Subdomains in Search Query Statements and Sponsored results on a Subdomain-By-Subdomain Basis"란 명칭의 미국 임시 특허출원 제60/460,658호로부터 35USC§119 하에서 우선권의 이익을 청구하며, 그 개시내용은 참고로 본 명세서에 일체화되어 있다.

콘텐츠 검색 시스템에서, 사용자는 콘텐츠를 요청하고 그 요청과 매칭하는 콘텐츠를 수신한다. 사용자는 요청을 처리하고/하거나 다른 컴퓨터 시스템에 요청을 전송하는 컴퓨터의 사용자 인터페이스와 인터페이스하는 휴먼 사용자일 수 있다. 사용자는 요청을 프로그램적으로 생성하는 다른 컴퓨터 프로세스 또는 시스템 일 수도 있다. 후자의 경우에, 요청하는 컴퓨터 사용자가 요청의 결과를 또한 프로그램적으로 처리할 것 같지만, 그 대신에 컴퓨터 사용자가 요청을 행하고 휴먼 사용자가 응답의 최종 수취인인 경우일 수 있거나, 반대로 휴먼 사용자가 요청을 행하고 컴퓨터 사용자가 응답의 최종 수취인인 경우일 수 있다.

콘텐츠 검색 시스템은 공용이다. 현재의 하나의 공용 시스템은 인터넷, 즉 네트워크의 글로벌 인터네트워크라고 하며, 네트워크의 노드가 콘텐츠로 응답할 수 있는 다른 노드에 요청을 전송한다. 콘텐츠 요청을 위해 사용 가능한 하나의 프로토콜은 하이퍼텍스트 전송 프로토콜(HTTP)이고, (브라우저와 같은) HTTP 클라이언트가 URL(Uniform Resource Locator)에 의해 참조되는 콘텐츠에 대한 요청을 행하고, HTTP 서버는 URL에 의해 특정된 콘텐츠를 전송함으로써 요청에 응답한다. 물론, 이것은 매우 일반적인 예이지만, 콘텐츠 검색이 그것에 제한되는 것은 아니다.

예를 들면, 토큰 링(token ring), WAP, 오버레이(overlay), 지점간(point-to-point), 사설 네트워크 등과 같은 인터넷과 다른 네트워크가 사용될 수 있다. SMTP, FTP 등과 같은 HTTP와 다른 프로토콜이 콘텐츠를 요청 및 전송하는데 사용될 수 있고, 콘텐츠가 URL 이외의 것에 의해 특정될 수 있다. 본 발명의 부분들은 다양한 응용을 위해 현재 공용의 네트워크의 글로벌 인터네트워크인 인터넷을 참조하여 설명하지만, 인터넷에 대한 참조는 인터넷의 기본 개념의 변형(예컨대, 인트라넷, 가상 개인 네트워크, 엔클로저드(enclosed) TCP/IP 네트워크 등)뿐만 아니라 다른 형태의 네트워크를 참조하여 대체될 수 있음을 이해해야 한다. 또한, 본 발명은 하나의 컴퓨터 또는 컴퓨터들의 하나의 모임 내에서 전체적으로 동작할 수 있 으므로, 네트워크에 대한 필요성이 없음을 이해해야 한다.

콘텐츠 자체는 다수의 형태로 있을 수 있다. 예를 들면, 어떤 콘텐츠는 텍스트, 이미지, 비디오, 오디오, 애니메이션, 프로그램 코드, 데이터 구조, 포맷된 텍스트 등일 수 있다. 예를 들면, 사용자는 다른 콘텐츠(동시에 사용되는 하이퍼텍스트 마크업 언어(HTML)에 따라 콘텐츠를 포맷함으로써와 같은)에 링크한 상태로 뉴스 스토리(텍스트)를 갖고 이미지를 첨부한 콘텐츠를 요청할 수 있다.

HTML은 HTTP 서버로부터 공급되는 페이지 또는 다른 콘텐츠용으로 사용되는 공통 포맷이다. HTML 포맷된 콘텐츠는 다른 HTML 콘텐츠로의 링크를 포함할 수 있고, 다른 콘텐츠를 참조하는 콘텐츠의 모임은 문서 웹으로 간주될 수 있으므로, 명 "World Wide Web" 또는 "WWW"가 HTML 포맷된 콘텐츠의 모임의 일례로 제공된다. 그것이 잘 공지되어 있는 구성이므로, 여기에서는 다수의 예에서 사용되지만, 달리 특정되지 않으면, 이들 예에서 설명되는 개념은 WWW, HTML, HTTP, 인터넷 등에 제한되지 않음을 이해해야 한다.

어떤 경우에는, 콘텐츠가 고유하게 식별되는 콘텐츠 객체에 대한 요청에 응답하여 액세스된다. 예를 들면, Yahoo! Sports 속성에 대해 Yahoo!의 홈페이지의 콘텐츠를 얻기 위해 찾는 사용자는 웹 브라우저 클라이언트를 개시하여 URL 내에 그러한 목적을 위해 웹 브라우저 클라이언트에 의해 제공되는 다이얼로그 박스에 sports.yahoo.com을 입력할 수 있다. 그러한 요청에 응답하여, 웹 브라우저 클라이언트는 HTTP 및 HTTPS와 같은 요청/응답 프로토콜과 관계가 있는 것으로 잘 알려진 바와 같은 요청된 페이지에 응답하는 특정 서버에 특정 페이지에 대한 요청을 행한다.

다른 경우에, 사용자는 특정 URL을 고려하지 않을 수 있고, 대신에 검색 질의의 형태로 콘텐츠의 대한 더욱 일반적인 요청을 발행할 수 있다. 일반적인 검색 질의에서, 사용자에게는 사용자가 검색 질의 용어를 입력하고 그들 용어에 기초하여 요청을 개시하는 다이얼로그 박스가 제공된다. 검색의 일례는 Yahoo! 검색이다. Yahoo! 검색을 실행하는 하나의 방법은 URL www.yahoo.com을 갖는 페이지에 웹 브라우저 클라이언트를 송신하고, 그 페이지 상에 제공되는 검색 다이얼로그 박스에 검색 질의를 입력하는 것이다. 웹 브라우저 클라이언트가 www.yahoo.com 서버(또는 페이지의 HTML에 포함되는 참조 또는 다른 코드에 의해지시되는 바와 같은 다른 서버)에 전송하는 그러한 질의에 응답하여, 수신 서버는 차례로 검색을 실행하거나 검색이 실행되게 하고, 일반적으로 페이지 또는 페이지들의 형태로 웹 브라우저 클라이언트에 검색 결과를 답변한다.

현재 사용하는 검색 및 응답의 하나의 변형에서, 사용자는 일반적으로 스페이스나 콤마와 같은 구획 문자(delimiters)에 의해 분리되는 하나 이상의 워드나 개념(토큰)의 형태로 하나 이상의 문자의 열을 입력하고, 검색 결과는 발견된 경우로 구성되는 여러 개의 검색 결과를 포함하는 페이지이다. 예를 들면, 검색 결과 페이지는 "Inside Yahoo!" 히트와 매칭하고, Yahoo! 디렉토리 히트와 매칭하며, 스폰서 히트와 매칭하고, 웹 검색 히트와 매칭하는 등을 리스트할 수 있다. "매칭"은 상이한 검색 상황에서 상이한 의미를 가질 수 있음을 이해해야 한다. 예를 들면, 어떤 검색 상황에서, 매칭은 정확하고, 다른 검색 상황에서는 매칭은 단일의 형태 및 대응하는 복수의 형태들이 상대로 고려되는 경우와 같이 대략적이다.

어떤 검색은 모든 사용 가능한 문서에 대해 실행되지만, 다른 검색은 검색되도록 사용 가능한 문서의 하나 이상의 서브도메인에 대해 실행될 수 있다. 예를 들면, 모든 공개 Yahoo! 속성은 검색에 사용 가능할 수 있지만, Yahoo! 여행 속성이나 Yahoo! 스포츠 속성에 제한된 검색이 바람직할 수 있다. 종종 질의를 생성하는 사용자는 검색할 서브도메인이 무엇인지를 알고, 자신의 검색을 그것에 제한할 수 있다. 그러나, 이것은 일반적으로 특정 서브도메인과 관련된 페이지에 네비게이트하는 것과 거기에 검색 용어를 입력하는 것과 같은 여분의 단계들을 필요로 한다.

서브도메인 검색을 위한 하나의 해법은 브라우저나 다른 소프트웨어에 서브도메인과 관련된 다양한 페이지로 어떻게 검색을 실행하는지를 나타내는 XML 파일에 맵하는 검색 워드에 기초하여 검색을 처리하는 검색 다이얼로그 박스를 제공하는 것이다. 예를 들면, "dic"로 시작하는 검색 문자열은 클라이언트가 "dic" 명령과 관련되는 페이지 상에 제공되는 검색 다이얼로그 박스로 나머지 요지를 사용자가 어떻게 입력할지를 시뮬레이트하는 것에 대한 지시를 포함하는 XML 파일 dic.xml에 의해 처리된다. 이것은 구조의 변화가 있는 페이지에 대해 잘 작용하지만, 사용되는 페이지는 일반적으로 클라이언트의 제허아에 있지 않고, XML 파일은 클라이언트에 국한하여 저장된다. 이로 인해, 예컨대, dic.xml 파일이 송신되는 사전 웹 사이트의 유지자가 페이지의 구조를 변경할 때, 검색은 각 클라이언트에게 그러한 변경된 페이지에 액세스하고 검색의 사용자 엔트리를 시뮬레이트하기 위한 XML 지시를 재기입 또는 갱신하기 위해 필요한 적절한 동작을 행하는데 실패할 수 있다.

필요한 것은 서브도메인과 다른 기술을 사용하는 향상된 검색이다.

본 발명의 실시예에 따르는 검색 시스템은 검색 질의가 서브도메인에 경로 설정되는지를 결정하기 위해 검색 질의를 분석하고, 서브도메인을 기초로 서브도메인 상에 스폰서되는 스폰서 히트를 포함하는 결과를 제공한다.

본 발명의 다른 특징 및 이점은 이하의 상세한 설명 및 바람직한 실시예를 보면 명확해진다.

도 1은 본 발명의 실시예에 따르는 검색 시스템의 블록도이다.

도 2는 도 1의 검색 서버의 구성요소들을 더욱 상세하게 도시하는 블록도이다.

도 3은 검색 결과 페이지의 도면이다.

도 4는 서브도메인 검색으로 파싱 가능하게 되는 검색 시퀀스의 허용을 위해 사용자에게 제공될 수 있는 페이지의 도면이다.

도 5는 북마크 검색인 서브도메인 검색으로 파싱 가능하게 되는 검색 시퀀스의 허용을 위해 사용자에게 제공될 수 있는 페이지의 도면이다.

도 6은 검색 서버의 다른 변형의 블록도이다.

도 7은 검색 서버의 다른 구성요소를 도시하는 도면이다.

도 8은 검색 질의를 파싱 및 분석하고 필요한 만큼 서브도메인 검색을 실시하는 프로세스의 플로우차트이다.

도 9는 여기에 기술된 바와 같이 수신되어 분석되는 질의를 처리하는데 사용될 수 있는 배포 질의 핸들링 시스템의 블록도이다.

도 10은 위치가 강조될 수 있는 검색을 위한 하나의 가능한 처리 흐름의 플로우차트이다.

부록 A는 힌트의 리스트, 즉, 특정 서브도메인으로 검색을 제한하는데 사용되는 힌트 키워드로서 사용될 수 있는 서브도메인 키워드의 일례이다.

본 발명의 실시예는 예로서 설명하지만 제한하고자 하는 것은 아니다. 본 발명은 광범위하게 이용되고 다수의 상이한 상황에서 사용될 수 있음을 이해해야 한다.

이하 설명하는 바와 같은 검색 프로세스의 예는 검색 시스템에 질의를 제공하고 찾아낸 하나 이상의 "히트"를 나타내는 응답(검색 결과)를 수신하는 검색자에 의해 모델화될 수 있다. 질의는 구획 문자 또는 파싱 규칙에 의해 경계가 정해지는 하나 이상의 토큰을 포함하는 검색 질의 문자열의 형태일 수 있다. 검색 질의 문자열의 변형에 기초하여 검색을 변경하는 것에 부가하여, 상황이 또한 고려될 수 있다. 예를 들어, 질의자는 연령에 맞는 히트만을 답변하도록 하는 것과 같은 검색에 대한 제한을 사전에 설정할 수 있고, 이전의 검색, 질의자 ID(검색 질이 문자열을 제공하는 웹 브라우저 클라이언트와 현재 관련되는 Yahoo! ID와 같은) 및 사 용자에 의해 설정되는 세팅도 고려될 수 있다.

검색 시스템에 의해 질의가 수신될 때, 검색 시스템은 검색을 처리하고 하나 이상의 "히트"를 답변하고, 여기에서 "히트"는 검색 시스템에 의해 다루어지는 극소 단위(atomic unit)이다. 예를 들어, 검색 시스템이 구성된 데이터베이스를 관리하는 곳에, 히트가 구성된 데이터베이스로부터 기록된다. 검색 시스템이 텍스트 문서, 이미지 및 텍스트 문서, 이미지 문서, HTML 문서, PDF 문서 등과 같은 문서들을 관리하는 경우에, 극소 단위는 문서이다. 본 발명은 어떤 특정 극소 단위에 한정되는 것이 아니라 이 개시물의 대부분이 극소 단위로 문서를 사용하는 검색을 설명하는 것은 예일 뿐이라는 것을 이해해야 한다. 더욱이, 구성된 데이터베이스는 불필요하다.

히트는 검색 시스템이 질의에 의해 정해지는 매칭 기준으로 식별하는 극소 단위이다. 검색 시스템은 질의에 매치하는 모든 히트나 히트만을 제공할 필요는 없음을 이해해야 한다. 예를 들어, 검색 시스템은 답변되는 히트의 수를 몇 개로 제한할 수 있고, 질의에 매치하는 히트를 생략하고, 중복하는 히트를 무시하는 등과 같이, 질의 조건에 다른 제한을 적용할 수 있다. 검색 시스템은 질의와 거의 매치하는 히트, 특별한 토픽 히트, 광고 히트 등과 같은 검색에 포함되도록 지정된 히트를 포함하도록 검색 결과를 확장할 수도 있다. 일부 확장 또는 단축은 그러한 확장이나 단축에 앞서 검색 결과의 크기나 콘텐츠에 의존할 수 있다. 예를 들어, 검색 엔진은 달리 답변되는 히트가 없는 경우 근접한 히트를 추가할 수 있고, 검색 결과를 완료하기에 앞서 질의로부터 공통 워드를 삭제하는 것과 같이 너무 많은 히 트가 답변되면 히트를 제거할 수 있다.

검색자는 웹을 통해 검색 엔진에 질의하기 위해 브라우저 윈도우에 검색 용어를 타이핑하는 사람과 같은 휴먼 사용자일 수 있지만, 검색 엔진에 검색 엔진에 의해 기대되는 형태로 질의를 전송할 수 있는 컴퓨터 프로그램과 같은 자동 프로세스일 수도 있다. 예를 들어, 컴퓨터 프로그램은 질의를 생성하고, 검색 엔진에 결합된 웹 서버에 송신되는 HTTP 메시지를 형성할 수 있다.

여기에 도시하는 다수의 예들에서, 검색 엔진은 문서들의 세트 중에서 질의에 의해 정해진 기준에 매치하는 문서(히트)를 검색한다. 용어 "문서"는 검색되는 코퍼스의 단위를 칭하는데 통상 사용되는 것을 이해해야 한다. 문서는 계약, 파일, 스토리, 기입 등과 같은 문서일 수 있지만, 다른 상황에서의 문서의 중요부, 프로그램 코드, 이미지 데이터, 저장된 파일 등일 수 있는 텍스트의 단편, 데이터일 수도 있다. 따라서, 이 용어는 좁게 해석될 필요는 없다.

검색 시에, 검색 엔진은 인덱스한 모든 사용 가능한 문서로부터 얻을 수 있지만, 검색 엔진은 그 대신에 하나 이상의 서브도메인 내의 문서만으로 검색을 제한할 수 있고, 여기에서 서브도메인은 검색 엔진에 사용 가능한 모든 문서의 사전에 지정된 적절한 서브세트이다. 어떤 경우에는, 서브도메인은 더 작은 서브도메인으로 더욱 분할될 수 있다.

서브도메인의 예들은 Yahoo! 속성이다. Yahoo! 속성의 예들은 Yahoo! 뉴스, Yahoo! 스포츠, Yahoo! 메일, Yahoo! 쇼핑, Yahoo! 옥션, Yahoo! 날씨 등을 포함한다. 서브도메인은 질의를 하는 사용자가 종종 특정 도메인 외부의 정보가 그 경우 에 유용하지 않은 것을 알기 때문에, 유용한 검색 도구이다. 예를 들어, 사용자가 뉴욕의 날씨 정보를 얻는 것에 관심이 있을 수 있다. 전체적인 검색은 뉴욕의 날씨를 부수적으로 언급하는 다수의 스포츠 스토리를 포착할 수 있지만, 사용자는 Yahoo! 날씨 속성 이외의 어떠한 히트도 유용하지 않다고 이미 결정하였을 수도 있다. 다른 예로서, 사용자는 모든 Yahoo! 속성 또는 웹 페이지에 대해 검색되는 경우 수천개의 히트이지만, 저장된 이메일 내의 몇 개의 히트만을 결과로 생성하는 키워드를 사용하여 자신의 저장된 Yahoo! 이메일을 검색하길 원할 수도 있다. 서브도메인을 사용하는 하나의 장점은 사용자가 다이얼로그 박스와 같은 일반적인 검색 입력 대상에 검색을 입력할 수 있고, 검색 서버가 사용자가 의도한 서브도메인(들)을 결정하도록 검색 질의 문자열을 분석하게 할 수 있다는 것이다. 서브도메인을 사용하는 다른 장점은 예를 들어, 사용자에게 무료로 제공되는 검색 서비스를 지원할 수 있는 스폰서 링크 또는 목표하는 광고가 서브도메인 별로 스폰서 및 광고주에게 할당될 수 있는 스폰서 링크 또는 광고라는 것이다.

이하 도면을 참조하여, 예시적인 검색 시스템을 설명한다.

도 1은 본 발명의 실시예에 따르는 검색 시스템(100)의 블록도이다. 검색 시스템(100)을 사용하여, 질의자가 웹 브라우저 클라이언트와 같은 검색 클라이언트를 사용하는 검색 서버에 검색 요청을 발행한다. 도 1에 도시된 바와 같이, 휴먼 사용자(103) 또는 컴퓨터 프로세스(105)는 검색 클라이언트(110)를 사용하여 질의를 발행한다. 일반적으로 검색 질의 문자열의 형태의 검색 질의는 검색 서버(120)에 송신되고, 검색 서버(120)는 검색 질의에 응답하여 검색 결과를 검색 클라 이언트(110)에 답변한다. 다른 변형에서는, 검색 질의는 하나의 시스템으로부터 오고 그 결과는 다른 시스템으로 경로 설정된다.

검색 서버(120)는 대응하는 서브도메인 코퍼스(132)에 차례로 결합되는 여러 개의 서브도메인 서버(130)에 결합된 것으로 도시되어 있다. 저장 효율성 또는 다른 이유로, 서브도메인 코퍼스의 콘텐츠 또는 정보는 일부 콘텐츠 또는 정보가 하나 이상의 서브도메인 코퍼스 내에 존재하도록 중첩할 수 있음을 이해해야 한다. 이 개시물 전체에 걸쳐, 하나의 대상의 복수의 경우가 있고 경우가 수가 임계적이지 않은 경우, 경우들은 다른 표시가 없으면 N의 값이 사용시마다 동일할 필요는 없다고 이해하여 "1"에서 "N"까지의 숫자가 부여된다. 예를 들면, N은 서브도메인의 수로 사용되지만, 그 수는 예별로 변할 수 있다. 또한 여기에서 모든 경우가 사용될 필요가 없음을 이해해야 한다.

다양한 시스템간의 상호 접속은 그러한 상호 접속 방법이 잘 공지된 기술을 사용하여 달성될 수 있으므로, 상세히 설명할 필요는 없다. 예를 들어, 검색 클라이언트(110)는 웹 브라우저 클라이언트와 같은 HTTP 클라이언트를 실행하여 글로벌 인터넷과 같은 네트워크를 통해 상호 접속된 검색 서버(120)에서 실행하는 HTTP 서버와 통신하는 퍼스널 컴퓨터일 수 있다. 다른 실시예들도 본 발명의 범위 내에 있음을 이해해야 한다. 예를 들면, 검색 클라이언트(110)는 휴대용 디바이스, 휴먼 사용자 인터페이스 없는 컴퓨터, 전용 디바이스, 키오스크 등으로 실시될 수 있다. 또한, 클라이언트 및 서버는 HTTP를 사용할 필요는 없지만, 페이지 및 대상에 대한 요청을 행하고 그들 요청에 응답하기 위한 상이한 프로토콜을 사용할 수 있 다.

동작 시에, 및 이하 더욱 상세하게 설명되는 바와 같이, 검색 클라이언트(110)는 요청을 전송하는 Yahoo! 사용자의 Yahoo! ID와 같은 상황 데이터를 또한 포함할 수 있는 검색 질의 문자열을 검색 서버(120)에 전송한다. 그러한 상황에서, 검색 서버(120)는 식별된 사용자의 사용자 인구통계를 일람하여 그것을 검색을 통지하는데 사용할 수 있다. 검색 서버(120)는 서브도메인 검색이 적절한지를 결정하도록 검색 질의 문자열을 파싱 및 분석한 후, 질의를 적절한 서브도메인(들)에 전송하거나 일반 검색을 실행한다. 예시한 바와 같이, 검색 결과는 검색 서버(120)에 의해 답변될 수 있지만, 그 대신에 서브도메인 서버에 의해 직접 답변될 수도 있다.

도 2는 검색 서버의 구성요소를 더욱 상세하게 도시한다. 도시된 바와 같이, 검색 서버는 페이지 구성자(200), 및 검색 결과(210)용 기억장치, 매칭 ads(212), 매칭 인서트(124), 스폰서 링크(216) 및 질의 로그(220)를 포함한다. 수신된 질의로부터, 검색 서버는 검색 자체를 실행하거나 다른 검색 엔진으로부터 결과를 요청함으로써 검색 결과(210)를 획득한다. 일반적으로, 검색은 키워드 인덱스와 같은 검색되는 코퍼스에 대한 인덱스를 사용하여 실행된다. 그 경우에, 검색 결과(210)는 인덱스에 기초하여 생성되는 히트이다. 페이지 구성자(200)는 기억장치(210-216)내의 구성요소로부터 페이지를 생성하여 그 페이지를 검색 질의에 대한 응답으로서 전송한다.

페이지 구성자(200)에 의해 구성된 페이지(300)의 일례를 도 3에 도시한다. 이 예에서, 검색 문자열은 "camera"였다. 페이지(300)는 상이한 페이지 레이아웃 영역(302, 304, 306, 308, 310, 312 및 314)로 구성되는 정보를 포함한다.

페이지(300)의 최상부는 검색의 표시, 다른 검색이 개시될 수 있는 다이얼로그 박스, 및 도움말, 홈 페이지 등의 클릭 가능 링크를 포함한다. "camera"에 대한 웹 인덱스로부터의 검색 결과와 같은 간단한 검색 결과가 레이아웃 영역(308)에 리스트된다. 이 예에서, 질의 문자열 "camera"를 사용하는 검색 질의 시에, 검색 서버는 웹 검색 결과를 갖는 기억장치(210)를 상주시키고, 가능하게는 다른 결과가 검색 문자열과 관련되는 광고를 갖는 기억장치(212)를 상주시키며, 검색 문자열과 관련된 인서트를 갖는 기억장치(214)를 상주시키고, 검색 문자열과 관련된 스폰서 링크를 갖는 기억장치(216)를 상주시킨다.

광고는 판매되는 뷰(view)가 어떤 것인지에 기초하여 선택될 수 있다. 따라서, 광고주는 검색 질의가 워드 "camera"를 포함하면 특정 광고가 검색 결과 페이지에 나타나게 하도록 지불할 수 있다. 스폰서 링크는 링크의 순서 및/또는 위치가 그 표시를 지불하는 사람과 검색 조건이 무엇인지에 의존할 수 있도록 유사하게 배치될 수도 있다.

레이아웃 영역(308)은 검색 조건에 응답하는 히트를 나타내고 바람직하게는 스폰서 링크가 누군지에 무관한 링크를 포함한다. 레이아웃 영역(310)은 매칭 광고, 또는 어떤 경우에 일반적인 광고의 삽입을 위해 제공된다. 레이아웃 영역(312, 214)은 사용되는 검색 용어에 특정되지만 일반적으로 검색 결과가 아닌 스폰서 매치 또는 광고주인 추가의 매칭 인서트를 제공한다. 이 예에서, 레이아웃 영 역(312)은 대안 검색을 실행하는 링크를 포함하고, 레이아웃 영역(314)은 대안으로 실행될 수 있는 서브도메인 특정 검색을 위한 링크를 포함한다.

그러나, 바람직한 실시예에서, 서브도메인 검색은 검색 질의 다이얼로그 박스로부터 첫째로 직접 실행될 수 있다. 예를 들면, 사용자가 자신이 카메라에 대한 옥션을 검색하는 경우, 사용자는 "camera"를 타이핑하는 것보다 직접 레이아웃 영역(314)에서 링크 "Yahoo! 옥션"을 선택하는 것을 나타낼 수 있다. 이것은 사용자의 시간 및 노력을 절약하고, 또한 더 많은 목표 인서트, 광고 및 스폰서 링크를 참작한다. 예를 들어, 사용자는 검색 문자열 "옥션 카메라"를 특정할 수 있고, 검색 서버는 첫번째 토큰 "옥션"을 적합한 검색 문자열의 일부 대신에 서브도메인 힌트인 것으로 해석할 수 있다. 그 경우에, 검색 서버는 검색 문자열 "카메라"를 Yahoo! 옥션에 특정된 서브도메인 서버에 송신한다.

검색 결과 페이지는 결과로서 더욱 초점이 맞춰질 것이다. 매칭 인서트는 검색 조건을 검색하는 옐로우 페이지용 링크를 포함하지 않을 수 있고, 스폰서 링크 및 광고가 선택될 수 있다. 따라서, 하나의 스폰서가 옥션 서브도메인 하에서가 아니라 일반 검색 또는 옐로우 페이지 서브도메인에서의 검색 하에서 용어 "camera"에 대한 스폰서 링크 위치를 구매하도록 선택할 수 있다. 이 방식으로, 광고 및 스폰서 링크가 더욱 초점이 맞춰질 수 있다. 이것은 예컨대, 고아고주가 옥션엣 카메라를 구매 또는 판매하기를 원하는 사용자에게 연락하기를 원하는 경우가 아니라 그 사용자가 로컬 카메라 상점의 위치를 찾는 경우 유용하다.

레이아웃 영역(302)은 매칭 인서트(214)를 표시한다. 이 예에서, 그들 매칭 인서트는 검색 조건에 관한 "Inside Yahoo!" 링크이다. 레이아웃 영역(304)은 Yahoo! 디렉토리, 토픽의 계층적 배열 및 이들 토픽과 계층적으로 여러 레벨에서 관련된 링크를 포함하는 서브도메인으로부터 매치되는 디렉토리 매치를 표시한다. 레이아웃 영역(306)은 특정 용어의 스폰서쉽에 기초하여 사용자에게 제공되는 히트인 스폰서 매치를 표시한다.

어떤 브라우저 또는 다른 입력 디바이스 구성에서, 사용자에게는 검색을 입력하고, 기호를 설정하며, 개인 힌트 세트(예컨대, 부록 A에 도시된 리스트의 서브세트일 수 있는 리스트)를 선택/편집하며, 메인 메일박스 페이지와 같은 검색 없이 어떤 서비스로 바로 점프하기 위한 툴바가 제공된다. 다른 예로서, "지도 서니베일 94089"에 대한 검색 질의는 검색이 필요 없이 캘리포니아, 서니베일의 지도에 대한 명백한 요청에 따라 지도 속성, 사이트 또는 시스템에 간단히 이동할 수 있다.

사용자가 "camera"와 같은 간단한 검색 질의를 입력할 수 있기 때문에, 사용자는 서브도메인에 적용될 수 있는 검색을 포함하는 더 복잡한 질의를 입력할 수도 있다. 예를 들어, 도 4에 도시된 다이얼로그 박스에 입력된 검색, "weather 94089"가 서브도메인에 적용될 수 있다. 일반 검색이 실행된 경우, 예컨대, 모든 웹 페이지에 대해, 검색이 유용한 것 이상의 히트 및 아마도 다수의 무관한 히트를 제공할 것이다. 그러나, 입력된 시퀀스가 파싱 가능한 서브도메인 검색으로 처리되면, 검색 서버는 날씨 검색 시스템의 서브도메인에 힌트인 것으로서 "weather"를 식별함으로써 질의를 처리하고, 날씨 검색 엔진에 요청을 전달한다.

어떤 실시에서는, 힌트는 서브도메인과 관련되는 단순한 워드가 아니다. 예를 들면, 검색 서버는 도움말이 힌트가 제공될 때를 결정하는 비즈니스 규칙의 세트를 유지할 수 있다. 예를 들면, 규칙은, 다섯 자리수로 시작하거나 종료하고, 서브도메인 힌트가 집 코드에 기초하는 검색을 제한할 때, 검색 문자열을 서브도메인 힌트를 갖는 것으로 해석할 수 있다. 따라서, "weather 94089"에 대한 검색은 2개의 힌트, 즉 검색이 Yahoo! 날씨 사이트와 같은 날씨 도메인에 대해 행해져야 하고, 검색이 집 코드 "94089"에 대응하는 영역으로 제한되어야 하는 것을 나타내는 "weather"를 포함할 수 있다.

다수의 힌트의 변형예가 가능하다. 예를 들면, "94089 pizza"는 다섯 자리 힌트로 시작하고 나타낸 집 코드 내의 피자 제공업자에 대한 검색이기 때문에, 옐로우 페이지 서브도메인에 대한 검색으로 해석될 수 있다. 어떤 실시에서는, 검색 서버는 사용자에 대한 개인화를 유지할 수도 있다. 개인화에 이해, 사용되는 힌트가 사용자에게 특정될 수 있다. 따라서, 한 사용자는 힌트 문자열 "res"가 resume 검색으로 해석되도록 개인화를 설정할 수 있지만, 다른 사용자는 힌트 문자열 "res"를 restaurant 검색으로 해석되도록 설정할 수 있다. 클라이언트에 보다는 검색 서버에 저장된 이들 개인화에 의해, 사용자는 상이한 위치에서 개인화되는 검색을 실행할 수 있다.

어던 경우에는, 개인화는, 검색 다이얼로그 박스가 북마크 검색으로서 효율적으로 사용될 수 있도록, 힌트가 하나의 히트만을 갖는 서브도메인에 대해서만 "검색"하는 정도로 될 수 있다. 따라서, 도 5에 도시된 바와 같이, 사용자는 자신 의 힌트를 "favteam"의 검색 질의 문자열이 사용자의 선호 스포츠 팀의 홈 페이지인 하나의 답변 히트를 결과로 생성하도록 개인화할 수 있다. 이것은 엄격하게는 검색이 아니지만, 답변된 페이지가 일반적으로 미리 특정된 특정 URL이므로, 동일한 인터페이스가 검색으로 사용될 수 있어 사용자에게 다이얼로그 박스의 더욱 통합된 인식을 유도한다. 서버 엔드에서는, 페이지 생성 프로세스 내의 일부 단계들이 북마크, 또는 "네비게이셔널", 검색에 대해 동일한 것일 수 있다. 예를 들면, 인서트, 광고 등의 매칭은 복수의 히트의 인덱스를 검색하는 서브도메인 검색으로 처리할 수 있다.

도 6은 검색 서버로 사용될 수 있는 여러 구성요소를 도시하는 블록도이다. 도시된 바와 같이, 검색 결과 및 서브도메인 특정 인서트/광고에 대해서 뿐만 아니라 일반 인서트/광고에 대해서도 기억장치가 제공된다. 검색을 개인화하는 검색 서버에 의해, "날씨가 너무 덥지 않은 곳"에 대한 검색은 히트, 인서트 및 광고의 결과 페이지를 결과로 생성할 수 있으며, 여기에서 인서트 및 광고는 검색을 실제로 실행하는 서브도메인에 의해 결정 및/또는 특정된다. 검색에 특정되지 않거나 서브도메인에 특정되지 않은 일반 인서트 및 광고가 또한 제공될 수 있다. 검색이 네비게이셔널 검색인 경우, 일반 인서트 및 광고는 라벨에 의해 추가의 상황이 결정될 수 없을지라도, 네비게이셔널 검색을 위한 북마크 또는 북마크 라벨과 관련된 URL로서 사용자에 의해 사용될 수 있다.

도 7은 사용자 선호를 위한 기억장치(700), 비즈니스 규칙을 위한 기억장치(702) 및 북마크 힌트를 위한 기억장치(704)를 포함하는 파싱 프로세스에 사용될 수 있는 것으로서의 기억장치를 도시하는 블록도이다. 기억장치(700)는 사용자의 표시 세팅 및/또는 선호의 모두 또는 서브세트를 포함할 수 있다. 예를 들면, 사용자의 세팅이 사용자의 Yahoo! 선호인 경우, 그것은 사용자의 연령, 위치, 성별, 취미 등을 포함할 수 있다. 비즈니스 규칙은 "날씨", "뉴스", "디렉토리 일람" 등과 같은 워드로부터 서브도메인가지의 맵핑을 포함할 수 있다. 비즈니스 규칙은 모든 사용자에게 동일하게 설정될 수 있거나, 일부 사용자가 커스터마이즈된 규칙을 가질 수 있다. 각 사용자는 커스터마이즈된 북마크를 가질 수 있지만, 일반적인 북마크의 세트가 존재할 수도 있다.

파서(710)가 검색 질의 문자열과 질의를 한 사용자의 표시를 수신할 때, 파서(710)는 문자열 내의 어떤 토큰이 힌트이고 적절한 서브도메인 서버에 적절한 검색 요청을 행하는지를 결정하도록 기억장치(700, 702, 704)의 콘텐츠를 사용할 수 있다. 검색 결과를 다시 수신하는 페이지 구성자는 검색 결과 페이지에 인서트 및/또는 광고를 포함할지를 결정하도록 기억장치(700, 702, 704)를 사용할 수 있다. 페이지 구성자가 그러한 정보(검색 서버에 쉽게 액세스 가능함)를 사용할 수 있기 때문에, 인서트 및 광고는 특정 서브도메인일 수 있다. 예를 들면, 검색 서버의 오퍼레이터는 서브도메인별로 특정 키워드에 대한 광고를 판매할 수 있다. 따라서, 하나의 피자점이 검색 조건 "피자"가 발생할 때 하나의 집 코드의 세트에 대한 모든 광고를 구매할 수 있는 한편, 매우 상이한 위치에 있는 다른 피자점은 또한 다른 집 코드의 세트에 대해서 "피자"에 대한 모든 광고를 구매할 수 있다. 이로 인해, 위치 의존 주문의 광고가 더욱 주목될 수 있다.

비즈니스 규칙(702)은 질의 로그(들)(706)의 콘텐츠에 기초하여 결정될 수 있다. 파서(710)의 동작은 과거의 동작에 기초하여 질의에 적용될 수 있는 다양한 규칙을 질의 로그(706)로부터 결정하는 휴리스틱스 생성기(720)로부터 차례로 생성될 수 있는 휴리스틱스(708)에 의해 영향을 받을 수 있다.

도 8은 검색 서버가 사용자로부터 수신된 검색 질의 문자열에 응답하여 검색을 파싱 및 달성하도록 실행할 수 있는 프로세스의 일례의 플로우차트이다. 이 예에서는, 서브도메인 검색 이외에 대해 적어도 하나의 힌트를 갖는 것으로 처리될 검색이 "!"와 같은 힌트 오퍼레이터 앞에 둔다. 어떤 실시에서는, 힌트 오퍼레이터가 필요없지만, 나머지에서는 이들 오퍼레이터가 불명료함을 감소시키고 정규 검색이 힌트로 간주되는 것을 사용하여 실행될 수 있게 한다. 도시된 바와 같이, 이 경우에는 힌트 오퍼레이터가 존재하지 않으면, 입력으로서 검색 질의 문자열을 사용하여 일반 웹 검색과 같은 일반 검색 프로세스가 호출된다. 어떤 경우에는, 초기 단계가 어느 부분이 힌트를 포함하는지를 결정하기 위해 검색 질의 문자열을 파싱한다. 다른 경우에는, 힌트가 함축적인 것으로 간주되어, 검색 서버가 함축적인 힌트가 부가될 때를 결정한다.

힌트 오퍼레이터가 존재하거나 함축되는 경우, 검색 질의 문자열이 파싱된다. 가변 비즈니스 규칙이 적용될 수 있지만, 여기에서는 일례가 제공된다. 제1 토큰이 다섯 자리이면, 먼저 집 코드로 해석되고 유효 집 코드의 리스트에 대해 체크된다. 토큰이 인식되지 않으면, 힌트 오퍼레이터가 사용되었을지라도 힌트가 인식되지 않은 메시지를 사용자에게 사용하여 정규 검색이 실행될 수 있다.

힌트가 인식되면, 힌트가 고려되지 않은 용어의 블랙리스트와 비교된다. 예를 들면, 검색 문자열 "!94089 Adventures"는 힌트 오퍼레이터, 94089의 집 코드 힌트 및 "adventures"의 나머지 검색 문자열로 해석될 수 있다. "94089 Adventures"가 대중 영화명인 경우, 이 검색 질의는 항상 오역될 것이다. 이것을 방지하기 위해, 문자열 "94089 Adventures"는 블랙리스트 상에 위치하여 그러한 문자열이 힌트없이 문자열로 해석되게 한다.

힌트 오퍼레이터가 존재하여 힌트가 검출되고 힌트는 블랙리스트 상에 존재하지 않는다고 가정하면, 힌트 토큰은 검색 서버에 의해 고려된다. 힌트가 사전 서브도메인 검색용이라면, 나머지 검색 문자열은 사전 서브도메인 검색 서버에 전달된다. 이것은 사용자의 클라이언트를 적절한 서버로 재송신함으로써 달성될 수 있다. 유사하게, 힌트가 날씨, 뉴스, 지도 등의 서브도메인 검색인 경우, 요청이 적절한 서브도메인에 송신된다.

지도, 옐로우 페이지 등의 서브도메인 검색의 경우, 어드레스 결정을 행하기 위해 추가의 힌트가 사용될 수 있다. 예를 들어, 검색 질의 무자열 "!yp 94089 parks"는 힌트 오퍼레이터, "yp"(옐로우 페이지) 힌트, 검색을 제한하는데 사용되는 "94089"의 추가의 힌트 및 "parks"의 나머지 문자열로 해석될 수 있다. 따라서, 상기 검색 질의 문자열은 94089의 집 코드를 갖는 것으로 제한된 공원에 대한 옐로우 페이지 서브도메인의 검색을 하게 한다. 집 코드(또는 우편 번호 또는 다른 표시)가 유효하지 않거나, 어드레스가 결정될 수 없는 경우, 응답은 일반 검색 및 에러 메시지일 수 있다. 어떤 경우에는, 위치가 식별될 수 없는 옐로우 페이지 검색과 같이, 응답이 에러 메시지일 수 있다.

일부 브라우저 또는 다른 입력 디바이스 구성에서, 사용자에게 검색을 입력하고, 선호를 설정하며, 개인 힌트 세트(예컨대, 부록 A에 도시된 리스트의 서브세트일 수 있는 리스트)를 선택/편집하고, 메일박스 페이지에 대한 요청으로 간주되는 검색 질의 문자열에 대한 메인 메일박스 페이지와 같은 검색 없이 어떤 서비스로 직접 점프하기 위한 툴바가 제공된다. 다른 예로서, "map sunnyvale 94089"에 대한 검색 질의는 검색을 필요로 하지 않고 캘리포니아, 서니베일의 지도에 대한 명백한 요청에 따라 지도 속성, 사이트 또는 시스템에 간단히 이동할 수 있다.

힌트 키워드로서 사용될 수 있는 서브도메인 키워드의 일례가 부록 A에 도시되어 있다. 이들 서브도메인 키워드는 검색을 특정 서브도메인으로 제한하는데 사용될 수 있고, 또한 그들 서브도메인 내에서의 검색에 영향을 주도록 사용될 수도 있다. 어떤 경우에는, 서브도메인에 의존하여, 검색 시스템이 검색과 다른 지시로서 검색 질의를 바꿀 수 있다. 예를 들면, 검색 시스템은 "mail from mom"을 메일 서브도메인에 대한 검색으로서 해석하여, 식별된 사용자의 메일 데이터베이스에 대해 "전송자=mom"으로부터의 메일을 검색할 수 있지만, 검색 시스템은 "!mail" 또는 간단히 "mail"을 사용자의 메일박스 내의 페이지와 같은 어떤 디폴트 조건에서 사용자의 메일 인터페이스를 오픈하라는 요청으로 해석할 수 있다.

일부 변형예에서는, 사용자는 검색 시스템이 그 사용자에 대해 힌트를 어떻게 해석하는지를 개인화할 수 있다. 이것을 행하기 위한 하나의 방법은 각 사용자에 대한 커스터마이즈된 바로가기(shortcut)의 세트, 유사한 사고의 사용자들의 그 룹, 또는 사용자들이 선택할 수 있는 커스터마이즈된 바로가기의 세트를 제공하는 것이다. 예를 들면, "music enthusiast" 커스터마이즈된 바로가기의 세트와 "oil driller" 커스터마이즈된 바로가기의 세트가 생성될 수 있고, 밴드의 드러머가 사용을 위해(또는 추가의 개인화를 위해 밴드로부터 베이스로서) "music enthusiast" 바로가기를 선택할 때, "drum store"에 대한 검색이 작은 북 등을 구매하는 장소에 대한 검색 결과를 유도하지만, 오일 산업에 대한 트러커(trucker)가 "oil driller" 커스터마이즈된 바로가기를 선택하여, 검색 "drum store"가 오일 드럼의 매도인을 유도하게 된다.

또 다른 검색 시스템 변형예에서는, 검색 시스템은 사용자 히스토리 및/또는 프로필에 기초하여 추가의 검색 또는 정보에 대한 제안을 제공할 수 있다. 예를 들면, 드러머에게 드럼에 대한 트리비아(trivia), 다른 드러머가 유용하다고 밝힌 추가의 유용한 검색 등과 같은 자발적인 정보가 제공될 수 있다.

또 다른 변형예에서는, 검색은 검색된 코퍼스의 소정부분에 대한 함축적인 제한을 포함할 수 있다. 따라서, 검색 사용자 또는 검색 시스템 오퍼레이터는 사용자 또는 오퍼레이터의 제어하에 있는 수직 응용을 위한 선호하는 처리를 포함할 수 있다. 이것은 먼저 공동 소유의 사이트를 찾기 위한, 또는 더 많은 검색에서 눈에 띄도록 그 콘텐츠를 변경하는 제3자의 간섭을 제한하기 위한 방법의 일부일 수 있다.

함축적인 힌트 동작의 일부로서, 검색 시스템은 함축적으로 논리 검색을 검출하기 위한 로직(logic)을 포함할 수 있다. 예를 들면, 자동 딜러쉽(dealership) 에 대한 대부분의 검색은 차량 판매자가 차량을 구매하기 위해 일반적으로 로컬 영역 외부로 가지 않기 때문에, 함축적으로 논리적이다. 따라서, 검색자가 "Ford dealership"을 입력할 때, 검색 시스템은 사용자의 집 코드(또는 집 코드 또는 위치에 가까운)의 함축적인 검색 힌트를 추가할 수 있다. 위치는 사용자가 식별되어 선호, IP/네트워크 어드레스, 이동 액세스 포인트(선호로부터 이동 디바이스 사용자가 그 어드레스보다는 현재 거주하는 곳에 국한된 정보를 찾기 위한)를 표시한 경우, 사용자 선호를 찾음으로써와 같이 다수의 방법으로 결정될 수 있다.

그러한 국한된 검색을 위해, 사용자에게는 일반 검색을 얻고 다른 위치를 선택하는 등을 위해 검색의 "장소"를 디스에이블할지에 관한 선택이 제공될 수 있다. 일 변형예에서는, 사용자에게 표시 요소들(컬러, 오프셋, 라벨 등)으로 서로 구별되도록 로컬 검색 결과 및 일반 검색 결과의 양자가 답변된다.

검색이 상이한 언어 또는 표현 형식을 갖는 지역에 대해 행해질 수 있는 경우, 위치 정보는 검색 질의를 자동으로 철자 체크하거나 해석하거나 그렇지 않으면 조정하기 위해 사용될 수 있다. 예를 들면, 검색 질의 "boot organizer"가 입력되어 검색이 북아메리카로부터 이루어진 것으로 검출되면, "shoe storage organizers"로 명확해질 수 있는 반면에, 검색이 영국이나 유사한 표현 형식의 다른 영어 사용 영역으로부터 이루어진 것으로 검출되면, 검색은 "automotive compartment storage units"로 명확해질 수 있다.

검색 시스템 오퍼레이터의 주문에 따라, 검색 질의의 일부가 검색을 입력하기 위해 사용자에 의해 취해진 경로 또는 광고나 콘텐츠 배치를 행하는 비즈니스 규칙을 고려하도록 파싱될 수 있다. 예를 들면, 사용자가 스포츠 페이지를 방문한 후 검색 엔트리 페이지로 점프하여 검색을 입력하면, 결과는 사용자가 스포츠 관련 페이지를 찾는데 현재 수반되는 지식에 의해 영향을 받을 수 있다. 따라서, "competition"에 대한 검색은 스포츠에서의 경쟁에 관련된 페이지를 제공할 수 있는 한편, 금융 페이지로부터 검색하는 사용자에게는 동일한 검색 문자열에 대해 비즈니스 경쟁에 관한 페이지가 제공될 것이다.

비즈니스 규칙 완수 결과에 대해, 검색 시스템은 취해진 소정 경로에 따른 소정 검색을 실행하는 사용자에게 자신의 광고만을 나타내게 하는 선택을 광고주에게 제공할 수 있어, "competition"에 대한 하나의 검색자는 필드 상에서의 경쟁력을 향상시키도록 스포츠 트레이닝 캠프에 대한 광고를 나타내는 반면에, "competition"에 대한 다른 검색자는 시장 및 산업 분석 서비스를 위한 광고를 나타낸다. 다른 예로서, 뉴스 경로로부터 "Washington"을 검색하는 사람은 정치적인 광고를 획득하는 반면, 여행 경로로로부터 "Washington"을 검색하는 사람은 날씨 페이지로의 프롬프트 또는 링크를 얻을 수 있다. 추가의 비즈니스 규칙은 명확화를 위해 사용 가능해질 수 있다.

특별히, 함축적인 힌트는 검색 질의 문자열 내의 특정 위치로 제한되지 않는다. 예를 들면, 검색 시스템은 문자열 "!weather 94089", "weather 94089", "Sunnyvale, CA weather", "what is the weather in area code 94089" 등의 어느 하나에서 "weather" 힌트를 결정할 수 있다. 물론, 검색 시스템은 검색 문자열에서 위치 힌트를 결정할 수도 있다. 검색 질의 문자열의 어떤 토큰 또는 토큰들이 힌트인가의 결정은 종종 공지의 의미를 갖는 워드의 일람표에 의해 결정될 수 있지만, 질의 로그가 어느 토큰들이 힌트인지를 결정하는데 사용될 수도 있다. 예를 들면, 질의 로그는 질의 로그 내의 엔트리가 사용된 검색 질의 문자열과, 사용자가 질의에 따라 선택한 질의 결과로부터 페이지의 식별 또는 표시(타이틀, URL 등)를 포함하는 곳을 유지될 수 있다. 예를 들면, 사용자가 검색 "Labrador"를 제출하여 캐나다와 관련된 페이지보다는 더 개와 관련된 결과 페이지가 거의 항상 선택되는 검색 결과를 얻은 것을 질의 로그가 나타내는 경우, 검색 시스템은 위치 힌트로서 Labrador를 사용하지 않을 수 있다. 따라서, 사용자가 "Labrador food"에 대한 검색을 입력할 때, 개 음식 사이트가 나타날 수 있다. 반면에, 질의 로그가 "Labrador"에 대한 대부분의 검색자가 캐나다 지방에 관한 링크를 클릭한 것을 기록한 것이 판명된 경우, 검색 시스템은 "Labrador food"에서 "Labrador"을 위치 힌트로서 사용할 것이고, 아마도 Newfoundland 및 Labrador의 캐나다 지방으로의 위치 제한을 갖는 식료품점 및 레스토랑을 검색 결과로 생성할 것이다.

질의 로그의 사용의 변형예에서, 힌트는 검색 시의 시간 변화의 없음을 통해 수집될 수 있다. 특정 엔티티에 대한 검색을 빠르게 못하게 하면, "뉴스"의 함축적인 힌트가 추가될 수 있다. 따라서, 사용자가 "Paris fashion"에 대한 검색을 제출할 때, 검색 시스템은 일반적으로 파리에서의 패션에 관한 페이지를 응답할 수 있지만, "Paris fashion"에 대한 질의 로그에서으 검색에 업 틱(up tick)이 있는 경우, 검색 시스템은 다수의 검색이 파리 패션 장면을 포함하는 어떤 단편 소설에 대한 정보를 찾는 경우 사용자가 의도한 것일 수 있는 뉴스 서브도메인 상에서의 검색에 초점을 맞출 수 있다.

다수의 검색이 처리됨에 따라, 단일의 검색 서버는 그러한 로드를 처리할 수 없을 수 있다. 그러한 상황을 다루기 위해, 검색 서버는 입력 질의가 송신되는 복수의 서버를 포함할 수 있다. 서버들은 검색 콘텐츠에 기초하여 선택될 수도 있지만, 로드를 더욱 벗어나도록 콘텐츠에 무관하게 선택될 수도 있다.

도 9는 복수의 검색 클라이언트가 문서의 코퍼스에 질의를 적용하도록 검색 시스템에 액세스할 수 있는 네트워크 시스템을 도시한다. 이 시스템에서, 하나 이상의(그러나 아마도 수천 이상의) 클라이언트 시스템(902)이 인터넷(904)을 통해 요청을 행한다. 요청은 HTTP 서버(906)를 통해 서버(908)에 흐르지만, 복수의 HTTP 서버가 존재할 수 있고, 다른 프로토콜이 HTTP 대신 또는 그에 추가하여 사용될 수 있음을 이해해야 한다. 서버(908)는 질의를 질의 프로세스(910)에 전송하고, 이 프로세스는 서버(908)내의 소프트웨어 객체의 예 또는 다른 예이거나, 하드웨어 구성을 포함할 수 있다. 질의 프로세스(910)는 검색 질의 문자열을 파싱하고, 하나 이상의 코퍼스(912)로부터 문서, 문서에 대한 참조, 링크 또는 히트의 다른 표시를 획득한다.

어떤 실시예에서는, 코퍼스(912)는 전체 코퍼스의 완전한 카피지만, 다른 실시예에서는 코퍼스(912)는 완전한 코퍼스의 서브세트이다. 후자의 경우, 서버(908) 또는 서버 프로세스(910)는 질의 및 다른 정보로부터 어느 코퍼스를 사용할지를 결정할 수 있다. 어떤 경우에는, 하나의 질의 프로세스(910)가 단일의 질의에 대해서도 하나 이상의 코퍼스(912)에 액세스할 수 있다. 일례로서, 별개의 서 브도메인이 별개의 코퍼스로 저장될 수 있다.

도 9에서, 복수의 객체의 예들이 클라이언트 시스템(902)에 대한 특정예에 대해 902(1)과 같은 괄호 표시에 의해 구분되어 있다. 다양한 객체에 대해, 터미널 인덱스는 "602(N1)"과 같은 어떤 불특정한 수이다. 객체의 수가 동일할 필요가 없는 경우, 터미널 인덱스들은 별개의 변수로 표시된다. 따라서, 정확히 3개의 서버(980)과 3개의 코퍼스(912)가 도 9에 도시되어 있지만, 도 9에 의해 함축된 N2(부정수) 서버와 N6(다른 부정수) 코퍼스(912)가 존재하므로, 서브와 코퍼스의 1대1 대응은 불필요하다. 달리 구체화하지 않으면, 상이한 터미널 인덱스가 1에서 1보다 큰 수까지의 범위에 있는 동일하거나 상이한 값을 가질 수 있다.

상기 예들에서는, 힌트가 파서(710)에 의해 해석된다. 어떤 선처리가 클라이언트에서 행해지는 것에 주의해야 한다. 어느 방법에서나, 해석은 결과적인 검색이 상이한 사용자에게 상이하도록 커스터마이즈될 수 있다. 따라서, 사용자 선호는 검색을 변화시킬 수 있고, 각 사용자는 자신의 커스텀 네비게이셔널 힌트의 세트를 가질 수 있다. 예를 들면, 하나의 사용자의 선호는 거주하는 시를 나타낼 수 있고, 그것은 검색을 알리는데 사용될 것이다. 예를 들면, 사용자의 선호가 "Sunnyvale, CA"를 거주하는 시로 나타내는 경우, 검색 질의 문자열 "!yp pizza"는 캘리포니아, 서니베일 내 또는 근처의 "피자"에 대한 옐로우 페이지 서브도메인에 대해 검색이 실행되게 할 수 있다. 5자리 집 코드를 사용하는 것에 추가하여, 6자리 우편 코드 등, 비즈니스 규칙은 위치로 해석하는 시의 리스트를 포함할 수 있다. 다른 선호는 부적절한 링크를 필터링하거나 사용자의 선호 언어로 검색을 제 한하는 것과 같이 필터링을 포함할 수 있다.

위치 특정 검색을 위해, 더 많은 초점이 맞춰진 결과가 서브도메인이 검색되는 곳이 위치에 따라 인덱스되는 것으로 기대될 수 있다. 시의 이름을 힌트로서 포함하는 검색에서, 서브도메인이 필터링되는 검색으로 변환될 수 있다. 예를 들면, 검색이 "Sunnyvale"을 포함하고 날씨 서브도메인과 같은 위치 인덱스된 서브도메인에 대한 것일 경우, 검색은 그러한 위치와 관련되고 나머지 검색 질의 문자열과 매치하는 페이지에 대한 것이다.

검색이 위치 특정된 것으로 식별될 때, 제공되는 인서트 및 광고도 또한 위치 특정된 것일 수 있다. 상기 일례에서, 위치 특정 검색에서의 "피자"에 대한 검색은 그 위치 내의 용어 "피자"를 사용하는 검색자에게만 광고하도록 선택하는 피자 판매인으로부터의 광고를 갖는 결과 페이지를 생성할 수 있다. 어떤 경우에는, 폭넓은 주제와 위치 특정 광고 캠페인이 광고주가 예컨대, 서브도메인이나 사용된 검색 용어에 무관한 위치와 관련된 검색 결과 페이지 상에 광고를 구매하도록 선택할 수 있는 위치에 지원될 수 있다. 실재로, 총 검색 결과 페이지의 수집은 검색 결과에만(통상적인 "키워드" 판매에서와 같이), 위치에만 또는 양자에 기초하여 광고나 인서트 캠페인에 대해 분할될 수 있다.

도 10은 위치가 함축될 수 있는 검색에 대한 하나의 가능한 처리 흐름의 플로우차트이다. 도시된 바와 같이, 검색 시스템은 검색을 수신한 후(S1), 위치일 수 있는 검색 질의 내의 것에 대해 체크한다(S2). 위치를 나타내는 것으로 나타나는 것이 없는 경우, 검색은 위치 지정 없이 처리된다(S3). 이어서, 단계 S4에서, 위치 표시는 예외인지를 결정하도록 체크된다. 예를 들면, 검색 질의 문자열이 "Taste of France restaurant menu"라고 가정한다. "France"는 위치로서 식별되지만, 검색 시스템은 레스토랑의 리스트를 유지하고 그등 중 하나가 "Taste of France"라고 한다고 추가로 가정한다. 그러한 경우, 검색은 "France"의 위치 지정을 갖고 검색되지 않는다. 검색 시스템은 위치 지정 없이 검색을 처리하고(단계 S3), 위치가 레스토랑에 대해 알려져 있을지라도 위치 지정은 거기로부터 행해질 수 있다. 단계 S2 및 S4(뿐만 아니라 다른 단계)의 처리는 있다면 어떤 토큰이 위치 힌트인지를 결정하거나, 함축적인 힌트를 제공하거나, 위치 자체를 결정하도록 질의 로그(들)의 콘텐츠를 사용할 수 있다.

위치 지정이 존재한다고 간주하면, 로컬 검색이 실행되고(S5), 검색은 위치 힌트가 제거된 상태로 검색 질의 문자열의 나머지의 위치 필터로 검색에 의해서와 같이 행해진다. 따라서, 검색 "restaurants in Burgundy, France"는 프랑스 Burgundy에 대한 위치 필터를 갖는 "restaurants"(또는 "restaurants in")에 대한 검식이 된다. 필터는 위치에 의해 수집된 코퍼스로 검색을 제한하거나, 공통 코퍼스로부터 히트와 관련된 다른 위치를 갖는 히트를 필터링하도록 동작할 수 있다.

이어서, 지도가 식별된 위치 및 적절한 옐로우 페이지 엔트리(S7)에 대해 얻어질 수 있거나(S6) 옐로우 페이지 엔트리에 대해 프롬프트할 수 있다. 그 후, 결과들, 지도(들), 옐로우 페이지 등이 사용자에게 답변되는 표시 페이지로 결합될 수 있다(S8).

어떤 힌트들은 "dic", "dictionary" 및 "define"과 같은 모두 사전 서브도메 인의 검색에 맵핑하는 동의어를 가질 수 있다. 어떤 힌트들은 "!weather Sunnyvale"과 "!Sunnyvale weather"과 같이 순서 변경이 허용될 수 있다.

어떤 힌트들은 Yahoo!의 사전 구조와 매치하는 용어와 같은 사전에 특정될 수 있다. 사전 특정 검색을 위해, 검색은 사전의 선택된 카테고리로 제한될 수 있다. 예를 들면, 검색 질의 문자열 "!directory lawyers Sunnyvale"은 페이지 상의 용어 "lawyer"를 갖고 생성되는 변호사의 페이지에 대한 검색이 아닌, 디렉토리 검색인 것을 나타내는 힌트를 갖고 서니베일에 위치 특정되는 검색 및 변호사에 대한 검색으로 파싱된다. 이것은 다수의 변호사의 페이지가 페이지 상에 자신의 이름을 갖지 않고 펌(firm) 이름의 일부가 아니면 페이지 상에 용어 "lawyer"를 갖지 않을 수 있으므로, 더욱 유용하게 되는 경향이 있다.

어떤 힌트들은 커스터마이즈된 명확한 힌트의 형태로 될 수 있고, 여기에서 사용자 선호는 검색에 사용되는 용어를 명확하게 하는데 사용된다. 예를 들면, 한 사용자는 "football"이 "soccer"를 칭하는 것을 나타내는 커스터마이즈된 명확성을 가질 수 있는 한편, 다른 사용자는 "football"이 "American football"을 칭하는 것을 나타내는 커스터마이즈된 명확성을 가질 수 있다.

이들 커스터마이즈된 명확한 힌트들은 급히 생성될 수 있다. 예를 들면, 사용자가 불명확한 것으로 플래그되어 이미 불명확하게 된 용어를 포함하는 검색 질의를 전송할 때, 사용자는 그 용어에 대한 선호하는 의미를 선택하도록 프롬프트될 수 있다. 다른 접근법에서는, 명확성은 불명확한 것으로 플래그되는 용어들로 제한되는 것이 아니라, 사용자가 검색 결과로부터 사용된 하나 이상의 용어가 명백히 불명확하다고 결정할 때마다의 옵션일 수 있다.

명확성을 위해, 이것은 키워드가 단 하나의 답변 페이지까지 검색을 완전히 명확하게 하도록 행해질 수 있다. 예를 들면, 사용자는 검색 질의 문자열 "football games"로 검색 서버에 검색을 전송하여 수천개의 페이지를 갖는 검색 결과 페이지를 얻을 수 있다. 검색 결과 페이지 상에, 사용자가 선호하는 페이지를 나타낼 수 있으면, 그 페이지는 그 용어를 사용하는 장래의 질의에 응답하여 제시된 페이지일 수 있다. 그러한 응답은 그 사용자에게 특정되지만, 검색 서버 오퍼레이터는 모든 사용자들 또는 사용자들의 일부 수집에 사용 가능하게 되는 글로벌 명확성을 실현하기 위해 선택할 수 있다.

또 다른 변형예에서는, 명확성을 위한 중간 접근법은 질의 용어와 관련된 특정 페이지의 특정 응답 및 모든 상이한 의미를 커버하는 일반적인 응답으로부터 다소 명확화하고, 사용자의 명확성은 용어의 해석의 횟수를 감소시킬 수 있다.

다수의 상기 예들에서, 검색되는 코퍼스는 일반적으로 액세스 가능한 코퍼스이다. 다른 변형예에서는, 코퍼스는 사용자가 검색할 수 있지만 검색 서버가 통상적으로 조작하지 않는 어떤 데이터베이스일 수 있다. 일례는 사용자에게 내부적으로만 사용 가능하게 될 수 있는 기업 종업원 일람이지만, 검색 서버에 의해 직접 액세스될 수 없다. 이 변형예에서는, 검색 서버는 액세스하지 않고 개인 데이터를 검색하기 위한 설비를 제공할 수도 있다. 예를 들면, 사용자는 대부분의 검색을 위해 사용되는 다이얼로그 박스에 가서, "!phone Joe Jones"를 타이핑할 수 있다. 검색 서버의 파서는 그것이 "phone" 서브도메인을 검색하라는 요청으로서 해석하 여, 검색 서버는 액세스할 수 없지만 클라이언트는 액세스할 수 있는 데이터베이스에 변형된 검색 질의 문자열을 갖는 클라이언트를 재송신한다. 그러나, 검색 서버는 일관된 보고 느끼기 위한 인서트 및/또는 광고를 제공할 수 있다.

검색 서버에 직접 사용 할 수 없는 코퍼스에 대한 더욱 일반화된 접근법에서는, 검색 서버는 검색을 파싱하여 그 검색을 처리할 수 있는 다른 서버에 그 검색을 중개할 수 있다. 검색 중개는 검색 서버 오퍼레이터와 중개된 검색 수용 시스템 사이의 동의를 수반할 수 있어, 다소의 값은 중개 서비스를 위한 교환 시에 소유주가 바뀐다.

본 발명은 바람직한 실시예를 참조하여 설명하였다. 당업자에게는 대체 및 치환이 명백해진다. 따라서, 본 발명을 첨부하는 청구의 범위에 의해 제공되는 것을 제외하고 한정하고자 하는 것은 아니다.

부록 A.

이 부록은 "!"(또는 힌트를 표시하는 다른 방법, 또는 함축적으로 힌트 제공)가 뒤따르는 검색 질의 문자열에서 사용될 때 서브도메인 특정 검색이 행해지게 하는 키워드의 리스트의 일례를 제공한다.

Claims

전자적으로 검색 가능한 콘텐츠에 디지털 방식으로 액세스하기 위해 컴퓨터 시스템을 사용하여, 요청에 응답하여 콘텐츠를 제공하는 방법으로서,

사용자로부터 검색 질의 문자열의 형태의 요청을 수신하는 단계;

상기 검색 질의 문자열이 하나 이상의 문자들의 힌트 문자열을 포함하는지를 판정하는 단계;

상기 검색 질의 문자열이 힌트 문자열을 포함하는 경우, 상기 검색 질의 문자열을 파싱(parsing)하는 단계 및

상기 힌트 문자열로부터 결정되는 하나 이상의 서브도메인에 대해 나머지 검색 질의 문자열을 처리하는 단계를 포함하고, 콘텐츠 제공 방법.
제1항에 있어서, 상기 힌트 문자열은 힌트 문자열 연산자를 포함하는, 콘텐츠 제공 방법.
제1항에 있어서, 상기 서브도메인은 지도, 전화 디렉토리 일람, 날씨, 뉴스, 쇼핑, 옥션, 이미지 및 계통적인 디렉토리 검색을 포함하는, 콘텐츠 제공 방법.
전자적으로 검색 가능한 콘텐츠에 디지털 방식으로 액세스하기 위해 컴퓨터 시스템을 사용하여, 적어도 하나의 검색 질의 문자열을 포함하는 검색 요청에 응답 하여 검색 결과를 제공하는 방법으로서,

상기 검색 질의 문자열을 토큰으로 파싱하는 단계;

토큰이 있다면 어느 토큰이 힌트 토큰인지를 판정하는 단계;

상기 검색 질의 문자열이 적어도 하나의 힌트 토큰을 포함하는 경우, 상기 검색 요청에 힌트 송신 동작을 실행하는 단계로서, 상기 힌트 송신 동작은 검색 엔진에 상기 적어도 하나의 힌트 토큰 미만의 상기 검색 질의 문자열에 대응하는 문자열인 나머지 검색 문자열을 제공하는 단계, 상기 검색 요청을 하나 이상의 상기 힌트 토큰에 의해 나타나는 검색 시스템에 송신하는 단계, 및 상기 검색 요청에 하나 이상의 힌트 토큰에 의해 나타난 파라미터들을 부가하는 단계 중의 하나 이상의 단계를 포함하며;

상기 검색 질의 문자열이 적어도 하나의 힌트 토큰을 포함하지 않는 경우, 상기 검색 요청을 디폴트 검색 엔진에 제공하는 단계를 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 상기 검색 요청에 부가된 상기 파라미터들은 하나 이상의 제어 스위치 및 추가의 검색 용어들을 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 어느 토큰이 힌트 토큰인지를 판정하는 단계는 상기 토큰을 발견적으로 결정된 비즈니스 규칙의 세트를 사용하여 분석하는 단계를 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 어느 토큰이 힌트 토큰인지를 판정하는 단계는,

이전의 질의의 히스토리를 유지하는 질의 로그 내에서 하나 이상의 상기 토큰의 매치를 찾는 단계;

상기 질의 로그 내의 매치에 기초하여 힌트 토큰을 갖는 토큰을 식별하는 단계를 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 어느 토큰이 힌트 토큰인지를 판정하는 단계는 검색 서버에 의해 유지되는 가능한 힌트 토큰의 테이블을 분석하는 단계를 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 이전의 질의 동작에 기초하여 함축적인 힌트를 추론하는 단계를 더 포함하는, 검색 결과 제공 방법.
제4항에 있어서, 적어도 하나의 힌트 토큰을 갖는 검색 질의 문자열은 나머지 검색 문자열 및 하나 이상의 힌트 토큰으로 파싱되고, 상기 나머지 검색 문자열은 힌트 토큰에 의해 힌트가 주어진 서브도메인에 송신되는, 검색 결과 제공 방법.
제4항에 있어서, 적어도 하나의 힌트 토큰을 갖는 검색 질의 문자열은 나머지 검색 문자열 및 하나 이상의 힌트 토큰으로 파싱되고, 상기 나머지 검색 문자열 은 힌트 토큰에 의해 힌트가 주어진 코퍼스(corpus)에 대한 검색용 검색 엔진에 송신되는, 검색 결과 제공 방법.
제4항에 있어서,

상기 검색 질의 문자열이 적어도 하나의 힌트 토큰을 포함하는 경우, 상기 적어도 하나의 힌트 토큰 내에 적어도 하나의 위치 힌트 토큰이 있는지에 관한 초기 판정을 행하는 단계;

적어도 하나의 위치 힌트 토큰이 존재하는 경우, 위치 힌트 토큰이 위치 결정되지 않은 것으로 플래그된 예외에 대해 테스트하는 단계;

적어도 하나의 위치 힌트 토큰이 존재하고 위치 결정되지 않은 것으로 플래그된 경우, 위치에 근거한 검색을 실행하는 단계; 및

위치 힌트 토큰이 존재하지 않거나 존재하는 어떤 위치 힌트 토큰이 위치 결정되지 않은 것으로 플래그된 경우, 위치 무관 검색을 실행하는 단계를 더 포함하는, 검색 결과 제공 방법.
제12항에 있어서, 위치 토큰이 존재하면 위치 결정되지 않은 것으로 플래그되지 않은 위치 힌트 토큰으로 나타나는 위치의 지도를 생성하는 단계를 더 포함하는, 검색 결과 제공 방법.
제13항에 있어서, 상기 지도와 요청자에게 복귀되는 디스플레이 페이지 내의 상기 위치에 근거한 검색의 결과를 결합하는 단계를 더 포함하는, 검색 결과 제공 방법.