KR101222253B1

KR101222253B1 - 구조화된 데이터 검색 방법

Info

Publication number: KR101222253B1
Application number: KR1020087012449A
Authority: KR
Inventors: 빈두 레디; 조나단 브런스먼; 닝 모스버거; 구라브 라빈드라 바야; 사라 시라주딘; 데이비드 케일; 제니퍼 엘. 코젠스키; 아빈드 선다라라쟌; 푸닛 아가왈
Original assignee: 구글 인코포레이티드
Priority date: 2005-10-23
Filing date: 2005-12-13
Publication date: 2013-01-16
Also published as: JP2009512954A; CN101866347B; CN101341464A; JP5560258B2; JP5112324B2; EP1952273B1; US20070168331A1; AU2005337489B2; US8762372B2; US7933900B2; BRPI0520649A2; WO2007046830A2; CA2626860A1; AU2012200884A1; AU2005337489A1; CN101341464B; JP2012043477A; EP1952273A2; CA2626860C; WO2007046830A3

Abstract

본 발명은 사용자가 쿼리 결과를 더 필터링하기 위해 사용되는 라벨 또는 속성값을 특정함으로써 구조화된 데이터에 대한 검색을 걸러낼 수 있는 것과 관련된다.

라벨, 속성, 콜렉션, 데이터, 제공자, 구조화, 벌크, 업로드, 데이터, 유형

Description

구조화된 데이터 검색 방법{SEARCH OVER STRUCTURED DATA}

본 출원은 35 U.S.C.§119(e)에 따라 2005년 10월 23일에 출원되고, 발명자 Reddy 등이 발명한 미국 특허출원 제 11/256,883 호, 발명의 명칭 "구조화된 데이터에 속성 및 라벨을 추가하는 방법"에 대해 우선권을 주장한다. 본 출원은 2005년 10월 23일에 출원되고, 발명자 Reddy 등이 발명한 미국 특허 출원 제 11/257,282 호, 발명의 명칭 "구조화된 데이터 검색 방법"과도 관련되고, 이 출원들은 본 출원에 참조로서 포함되어 있다.

종래 검색 엔진은 월드 와이드 웹 또는 매우 큰 데이터베이스 같은 매우 큰 정보의 콜렉션(Collection)을 검색할 수 있다. 검색할 데이터 콜렉션의 크기가 커질수록, 사용자에 의해 입력된 쿼리 용어와 일치하는 쿼리 결과를 정확하게 얻을 수 없게 되었다. 대신에, 사용자가 검색으로부터 돌아온 대량의 데이터를 분류하도록 돕는 메커니즘(Mechanism)이 제공되는 것이 바람직하다.

현재, 다수의 종래 검색 엔진은 쿼리 결과로 돌아온 데이터를 조직화하기 위해 다양한 방법을 사용한다. 그러한 조직화 방법의 목표는 사용자가 가장 관심을 갖는 쿼리 결과를 결정하는 것이다. 종래 검색 엔진들은 일반적으로 검색 결과를 우선순위화하는 다양한 기술을 사용하지만, 이러한 기술은 사용자가 검색하는 정보의 유형에 대한 가정을 사용해야만 하기 때문에 이상적이지 않다. 예를 들어, 사용자가 "직업(Jobs)"을 입력했다면, 사용자는 직업 공고, 스티브 잡스(Steve Jobs)에 대한 정보, 특정 국가의 직업 통계, 또는 많은 다른 아이템들을 검색하게 된다. 따라서, 종래 검색 엔진을 사용할 때, 사용자는 쿼리 용어로 "직업"이라고만 입력해서는 안된다. 사용자는 아마도 검색을 좁혀 줄 추가적인 쿼리 용어도 입력해야 한다. 불행하게도, 사용자는 좁혀줄 용어를 포함하지 않는 적절한 목록을 놓치기도 한다.

현재, 월드 와이드 웹에 저장되거나 또는 저장되지 않는 서로 다른 유형의 데이터를 검색하는 것이 매우 어렵다. 종래 검색 엔진은 보통 소수의 소스만으로부터 데이터에 작용한다. 예를 들어, 웹 기반 검색 엔진은 전통적으로 사용자가 월드 와이드 웹 상에서 페이지를 검색하도록 한다. 보통 웹 검색 엔진은 정보 콜렉션을 검색 가능하도록 색인화하는 "후단(Back End)"을 포함한다. 예를 들어, 웹 기반 검색 엔진은 주기적으로 월드 와이드 웹을 탐색하고 탐색된 페이지와 사이트의 색인을 만든다. 다른 검색 엔진은 사용자가 현존하는 데이터베이스를 검색하도록 한다. 그러한 검색 엔진은 미리 결정된 데이터베이스 조직에 의존한다. 예를 들어, 데이터베이스가 알려진 영역 및 속성을 가지고 있으면, 사용자는 그러한 속성 내에서 검색할 수 있다. 예를 들어, XML 데이터베이스는 문법적으로 정확한 XML 입력만을 수용한다. 검색할 데이터가 잘 조직화되어 있지 않다면, XML 데이터베이스는 일반적으로 검색을 위해 데이터를 수용하거나 데이터를 조직할 수 없다.

다른 검색 엔진은 사용자가 데이터베이스를 검색하거나 또는 플랫(Flat) 조직을 가진 텍스트 문서를 검색하도록 한다. 그러한 검색 엔진은 데이터베이스의 조직 및 그 내부의 문서 조직에 대해 알고 있어야만 한다. 데이터가 저장되는 위치 및 포맷의 다양성은 사용자가 일반적으로 필요한 정보를 찾기 위해서 다중 데이터베이스의 다중 위치에서 검색을 해야 한다는 것을 의미한다.

문서 콜렉션은 웹 기반 검색 엔진을 통해 검색 가능하고 따라서 대부분의 사람들에게 쉽게 접속 가능하고, 동시에 다양한 유형의 문서 및 다양한 포맷의 데이터를 포함하는 것이 바람직하다. 추가적으로, 검색 가능한 문서 콜렉션이 사용자가 자신의 검색을 세부적으로 조율하도록 도울 수 있는 방법으로 조직화되는 것이 바람직하다.

본 발명의 실시예는 라벨 및 속성값과 검색할 데이터 아이템을 관련시킨다. 제공자는 속성 및 라벨을 자신들의 데이터와 관련시키거나, 속성 및 라벨을 현존하는 데이터에 추가시킬 수 있다. 바람직한 실시예는 콘텐츠 제공자가 자신의 개인화된 라벨 및 속성을 아이템에 첨부(Attach)하거나 또는 미리 정의된 라벨 및 속성을 사용할 수 있도록 한다. 제공자는 사용자 인터페이스 또는 벌크 업로드 메커니즘을 사용하여 데이터를 업로드(Upload)할 수 있다. 사용자는 쿼리의 결과를 추가로 필터링하기 위해 라벨 또는 속성값이 사용됨을 특정함으로써 검색을 걸러낼 수 있다.

본 발명의 사상(Teaching)은 이하의 발명의 상세한 설명을 첨부한 도면과 함께 고려함으로써 쉽게 이해될 수 있다. 첨부한 도면에서 동일한 참조 번호는 동일한 구성요소를 위해 사용된다.

도면은 본 발명의 실시예들을 예시의 목적으로만 나타낸다. 당업자는 이하의 발명의 상세한 설명으로부터 본원에 예시된 구조 및 방법의 대체적 실시예가 본원에 설명된 발명의 핵심을 벗어나지 않는 범위에서 개시됨을 쉽게 인식할 수 있을 것이다.

도 1a는 본 발명의 바람직한 실시예에 따른 데이터 처리 시스템을 도시하는 블록 다이어그램(Block Diagram)이다.

도 1b는 본 발명의 바람직한 실시예에 따른 다른 데이터 처리 시스템을 도시하는 블록 다이어그램이다.

도 1c는 본 발명의 바람직한 실시예에 따른 아키텍처(Architecture) 다이어그램이다.

도 2a는 본 발명의 바람직한 실시예에 따라 검색 가능한 데이터 아이템 콜렉션을 만드는 개관을 도시하는 순서도이다.

도 2b는 본 발명의 바람직한 실시예에 따라 문서 콜렉션을 검색하고 검색을 걸러내는 개관을 도시하는 순서도이다.

도 3a는 데이터 아이템 콜렉션으로부터 라벨 및 속성을 추출하는 방법을 도시하는 순서도이다.

도 3b는 쿼리 용어를 수신하고 쿼리 결과를 디스플레이하는 방법을 도시하는 순서도이다.

도 3c는 주어진 쿼리 결과에 대해 어떤 속성을 디스플레이할 것인지 결정하는 방법을 도시하는 순서도이다.

도 3d는 사용자가 디스플레이된 쿼리 결과를 라벨 및/또는 속성값을 사용하 여 걸러내도록 하는 방법을 도시하는 순서도이다.

도 3e는 제공자가 제공한 새로운 속성이 정보 유형에 따라 코어 속성에 추가되어야만 하는지를 결정하기 위해 주기적으로 수행되는 방법을 도시한다.

도 4a는 검색 엔진 및 사용자에 의해 입력된 쿼리 용어의 예시적 스크린 샷(Screen Shot)이다.

도 4b는 도 4a의 쿼리로부터 쿼리 결과를 도시하고, 쿼리 용어에 대한 쿼리 결과와 관련된 라벨 및 속성도 도시하는 예시적 스크린 샷이다.

도 4c 내지 4g는 추가적인 속성과 라벨, 및 어떻게 사용자가 속성 및/또는 라벨을 사용하여 검색을 좁히는지를 도시하는 예시적 스크린 샷이다.

도 5a는 검색 가능한 데이터 콜렉션을 위한 속성 및 라벨을 저장하기 위해 사용되는 데이터 포맷을 도시한다.

도 5b는 도 5a의 포맷을 사용하여 저장된 속성의 예를 도시한다.

도 5c는 도 5a의 포맷을 사용하여 저장된 라벨의 예를 도시한다.

도 5d는 정보 유형을 그 속성에 매핑(Mapping)시키기 위한 예시적 데이터 구조를 도시한다.

도 5e는 정보 유형에 따라 일부 예시적 속성에 매핑되는 정보 유형의 예를 도시한다.

도 6a 내지 6e는 제공자가 데이터를 편집하고 시스템에 입력하도록 하는 사용자 인터페이스를 도시하는 예시적 스크린 샷이다.

도 7은 벌크 업로드 파일을 등록하기 위한 사용자 인터페이스를 도시하는 예 시적 스크린 샷이다.

도 8a 내지 8d는 제공자가 데이터 및 속성값을 벌크 업로드하는 방법을 도시한다.

이하의 단락에서는 본 발명에 따라 구조화된 데이터를 업로드하고 검색하기 위한 시스템의 다양한 실시예를 설명한다.

도 1a는 본 발명의 바람직한 실시예에 따르는 데이터 처리 시스템을 도시하는 블록 다이어그램(100)이다. 도 1a는 다수의 클라이언트 데이터 처리 시스템(110a,...,110n), 네트워크(130), 및 서버 데이터 처리 시스템(120)을 포함한다. 도 1a에서, 예시적 사용자 데이터 처리 시스템(110a)은 프로세서(140), 브라우저(150), 및 메모리(160)를 포함한다. 사용자 데이터 처리 시스템(110) 또는 상기 시스템의 구성요소들은 개인용 컴퓨터, 유선 네트워크 컴퓨터, 무선 네트워크 컴퓨터, 모바일 전화기 또는 모바일 전화기를 포함하는 디바이스, 휴대용 디바이스, 신 클라이언트 디바이스(thin client device), 이들의 조합 등을 포함하는 어떠한 적절한 데이터 처리 시스템도 될 수 있지만 이들에 제한되지는 않는다. 네트워크(130)는 하나 이상의 사용자 데이터 처리 시스템(110)과 서버 데이터 처리 시스템(120) 사이의 통신을 가능하게 하는 어떠한 네트워크도 될 수 있다. 예를 들어, 네트워크(130)는 인터넷, LAN, WAN, 유선 네트워크, 무선 네트워크, 모바일 전화 네트워크, 문자 메시지를 송신하는 네트워크, 이들의 조합이 될 수 있지만 이들에 제한되지는 않는다.

본 발명의 바람직한 실시예에서, 사용자 데이터 처리 시스템(110a)은 사용자가 서버 시스템(120)과 통신할 수 있도록 하고 프로세서(140)에 의해 실행되는 브라우저 소프트웨어(150)를 메모리(160)에 포함한다. 이하에서 상세히 설명될 것처럼, 브라우저(150)는 사용자가 서버 데이터 처리 시스템(120)과 통신하게 하고, 쿼리 용어를 서버 데이터 처리 시스템(120)에 전송하며, 시스템(120)으로부터 쿼리 결과를 수신하게 한다. 이하에서 더 상세히 설명될 것처럼, 브라우저(150)는 사용자가 쿼리 결과와 관련된 라벨 및 속성을 수신하게 하고, 라벨 및 속성을 사용하여 쿼리 결과를 더욱 한정하기 위해 상기 라벨 및 속성을 사용하게 한다. 상기 실시예는 브라우저 기반이지만, 본 발명은 브라우저 기반의 검색에 제한되지 않고 사용자(110)와 서버(120) 사이의 어떠한 적절한 통신 메커니즘도 본 발명의 핵심 및 범위를 벗어나지 않는 범위에서 사용될 수 있다.

본원발명에 설명된 모든 소프트웨어 및 컴퓨터 실행 가능 명령어의 일부는 데이터 처리 시스템의 메모리, CD ROM, 플래시 메모리, 플로피 디스크를 포함하지만 이에 제한되지는 않고 컴퓨터 판독 가능한 매체에 컴퓨터 프로그램 제품으로 저장될 수 있고, 또는 네트워크를 통해 또는 시스템 구성요소들 사이에서 신호로서 송신될 수 있다.

서버 데이터 처리 시스템(120)은 서버 시스템(120)이 쿼리 용어를 구조화된 데이터 콜렉션(190)에서 검색할 수 있도록 하기 위해 검색 및 쿼리 엔진 소프트웨어(185)를 실행하는 프로세서(170)를 포함한다(검색 및 쿼리 엔진(185)은 "검색 엔진"으로도 불림). 구조화된 데이터의 일례는 필드화된(Fielded) 데이터, 즉 각각이 하나 이상의 데이터 필드(이름, 주소, 상태 등과 같은)를 갖는 데이터 아이템들이다.

메모리(180)는 속성 저장소(195)도 포함하는데, 이는 구조화된 데이터(190)에서 일부 또는 모든 데이터 아이템을 위한 속성(및 라벨)을 저장한다. 저장소는 도 5와 연관하여 이하에서 설명한다. 저장소(195)는 구조화된 데이터 콜렉션(190)의 일부처럼 도시되었지만, 저장소(195)는 데이터 콜렉션(190)으로부터 분리될 수도 있다.

큰 검색 엔진 및 큰 데이터 콜렉션은 분산(Distributed) 데이터 처리 시스템, 협동(Cooperating) 데이터 처리 시스템, 네트워크 데이터 처리 시스템 등을 포함하지만 이에 제한되지는 않는 많은 방식으로 저장될 수 있지만, 도 1a에서는 검색 엔진(185), 저장소(195), 및 구조화된 데이터 콜렉션(190) 모두가 단일 메모리(180) 내에 있는 것처럼 도시되었다. 검색 엔진(185)은 소프트웨어, 하드웨어, 펌웨어, 또는 이들의 어떠한 조합도 가능하다.

바람직한 실시예에서, 쿼리 용어는 하나 이상의 다수의 사용자 시스템(110)을 통해 사용자에 의해 입력되고, 네트워크(130)를 통해 서버 데이터 처리 시스템(120)으로 전송된다. 데이터 컬렉션을 수신, 색인화, 및 검색하기 위해 서버(120)에 의해 사용되는 방법의 자세한 내용이 본 발명에서 설명된다.

도 1b는 본 발명의 바람직한 실시예에 따른 다른 데이터 처리 시스템을 도시하는 블록 다이어그램(111)이다. 도 1b에서, 사용자는 자신의 기계(110)에 개인 데이터 콜렉션(190)을 저장한다. 개인 검색 엔진은, 사용자 및 가능하게는 네트워크(130)를 통해 다른 사용자에 의해 검색 가능하도록, 이 데이터에 접속하고 조직화하는 것이 고려된다. 또한, 그러한 시스템은 데이터베이스 및 다른 유형의 데이터 콜렉션이 중앙 검색 엔진에 의해 접속 가능한 검색 가능 문서의 풀(Pool)에 추가될 수 있도록 한다.

도 1b의 실시예에서, 데이터 콜렉션(190)은 사용자의 데이터 처리 시스템(110) 또는 엔터프라이즈(Enterprise) 서버(도시되지 않음)에 저장되고, 사용자, 사용자들 중 더 작은 부분 집합, 또는 데이터 콜렉션(190)에 접근하는 법을 알고 있는 모든 사용자와 같은 사람들 또는 개인들의 선택된 그룹이 이용 가능하도록 만들어진다. 그러한 경우에, 상기 설명한 것처럼 속성 및 라벨을 통해 검색을 필터링하는 기능은 컴퓨터 또는 컴퓨터들의 로컬 네트워크에서 지역적으로 실행되는 개인 검색 엔진(185)의 일부분이 될 수 있다. 예를 들어, 캘리포니아 마운틴 뷰에 있는 구글 사에서 제공하는 구글 데스크탑 검색 툴(tool)은 사용자의 데스크탑에서 실행되어 사용자의 개인용 컴퓨터 상에서 데이터를 색인화하는 검색 툴이다. 본 발명을 포함하는 구글 데스크탑 검색의 구현은 사용자에게 사용자의 데스크탑에 저장되거나 사용자의 데스크탑으로부터 접근 가능한 데이터베이스 및 다른 유형의 데이터 콜렉션을 검색하는 능력을 제공한다.

또한, 상기 구글 데스크탑의 구현은 사용자에게 유용한 속성 및 라벨로 자신의 데이터를 조직하기 위한 기능도 제공한다. 예를 들어, 대학 도서관은 대학의 학생, 교직원, 및 졸업생이 사용 가능한 모든 온라인 콜렉션을 만들 수 있다. 그러한 경우에, 정보는 공개적으로 사용 가능한 서버에 있지 않으나, 대학의 서버에 저장되고 대학 데이터 제공자에 의해 접근이 허락된 사람들(및 프로그램들)에게만 접근 및 검색이 가능할 수 있다. 이 예에서, 대학은 어떤 제공자가 데이터 콜렉션에 추가할 능력을 가지는지도 통제할 수 있다.

도 1c는 본 발명의 바람직한 실시예에 따르는 아키텍처 다이어그램(131)이다. 설명된 실시예에서, 제공자는 데이터 및 속성을 시스템에 입력하는 세 가지 방식 중 하나 이상을 사용할 수 있다. 제공자측 전단(Front End, 132)은 제공자가 그러한 목적을 위해 제공되는 사용자 인터페이스를 사용하여 데이터 아이템 및 속성을 입력하도록 한다(예를 들어, 도 6b 참조). 제공자는 데이터 아이템의 벌크 업로드(133)도 수행할 수 있다(예를 들어, 도 8a 내지 8d 참조). 제공자는 특정 URL로부터 아이템을 업로드(134)도 할 수 있다(예를 들어, FTP를 사용함). 검색 및 쿼리 엔진(185)은 데이터 콜렉션(190)의 아이템을 색인화하고, 데이터 콜렉션(190)은 바람직하게는 모든 데이터의 색인(137)을 생산하기 위해 데이터 아이템에 대하여 입력된 속성 및 속성값을 포함한다. 검색 엔진(185)은 사용자가 쿼리를 입력하도록 한다(예를 들어, 도 4a 참조). 시스템은 소프트웨어 프로그램이 검색 엔진(185)을 통해 데이터를 쿼리하도록 하는 API(Application Program Interface)도 포함한다.

도 2a는 본 발명의 바람직한 실시예에 따라 검색 가능한 데이터 아이템 콜렉션을 만드는 개관을 도시하는 순서도(200)이다. 도 6a 내지 6e 및 도 8a 내지 8d와 연관하여 이하에 설명된 것처럼, 서버(120)는 데이터 아이템 콜렉션을 수신한다(202). 이 데이터는 표준 웹 탐색의 결과로서 수신되거나 또는 자신의 데이터가 검색 가능하도록 되기를 원하는 하나 이상의 제공자에 의해 제공될 수 있다. 수신된 데이터 아이템 콜렉션은 이하에 설명될 것처럼 라벨, 속성, 및 속성값을 추출하기 위해 처리되고 그러한 라벨, 속성, 및 속성값은 다양한 정보 유형과 관련된다. 임의의 환경에서, 사용자는 입력된 데이터의 일부 또는 전체에 대하여 속성 이름 및/또는 속성값을 제공한다. 예를 들어, 사용자는 의학 저널 콜렉션을 보관하기 위해 만든 데이터베이스를 업로드할 수 있다. 사용자는 "저널", "발행 년도", "저널 이름"과 같은 속성이름을 반영하는 값으로 이러한 저널에 대한 속성을 특정할 수 있다. 사용자는 "의학", "치학", "하바드로부터" 등과 같은 저널 각각을 위한 0 개 이상의 라벨을 입력할 수 있다. 라벨은 그와 관련된 값을 갖지 않는 특별한 종류의 속성이다(값 없는 태그라고도 함). 요소(204)의 상세한 내용을 도 3a과 함께 설명한다.

도 2b는 본 발명의 바람직한 실시예에 따라 문서 콜렉션을 검색하고 검색을 걸러내는 개관을 도시하는 순서도(210)이다. 실시예에서, 사용자는 하나 이상의 쿼리 용어(도 4a의 스크린 샷(400)에서 "암 수용체(402)"와 같은 쿼리 용어)를 입력한다(212).

임의의 실시예에서, 사용자는 또한 속성 이름 및 값을 영역(402)에 입력된 쿼리의 일부로서 입력한다. 예를 들어, 사용자는 영역(402)에 다음의 내용을 입력할 수 있다.

암 수용체 속성(저널유형:의학)

쿼리 결과의 일부 아이템이 저널유형으로 명명된 속성을 가지지만 속성이 코어 속성 집합의 일부분이 아니라는 것을 사용자가 안다면, 사용자는 의학 저널만을 돌려받기를 원한다.

도 3b와 연관하여 이하에서 상세히 설명될 것처럼, 시스템은 쿼리 결과를 결정한다(213). 일부 실시예에서, 쿼리 결과는 이 시점에서 디스플레이된다(213). 다른 실시예에서, 쿼리 결과는 아직 디스플레이되지 않고, 대신에 사용자는 쿼리 용어에 특유의 라벨 및/또는 속성을 선택함으로써 자신의 검색을 더 걸러내도록 요청받는다. 예를 들어, 도 3d에 도시된 것처럼, 사용자는 라벨 및 속성을 특정함으로서 자신의 검색을 걸러낼 수 있다(214).

도 3a는 데이터 아이템 콜렉션으로부터 라벨 및 속성을 추출하는 방법을 도시하는 순서도이다. 이 방법은 데이터 콜렉션이 검색될 수 있도록 데이터 콜렉션을 조직화하기 위해 사용된 셋업(Set-up) 과정의 일부이다.

각각이 정보 유형을 가지는 데이터 아이템이 수신되면, 시스템은 이 정보 유형을 위한 라벨 및 속성을 결정한다(304). 속성은 "저널"과 같은 이름을 가지고, 하나 이상의 가능한 저널 이름의 값을 가지는 이름/값의 쌍(Pair)이다.

바람직한 실시예에서, 속성 및 라벨은 데이터 제공자에 의해 특정된다. 따라서, 속성의 결정은 사용자가 제공한 속성 및 라벨을 식별하는 문제에 불과하다.

임의의 경우에, 데이터 제공자는 자신의 아이템을 위한 속성 및 라벨을 특정하지 않는다. 예를 들어, 아이템이 웹 탐색자(Crawler)에 의해 위치된 웹 페이지라면, 웹 페이지의 소유자는 자신의 페이지를 위한 속성 또는 라벨을 특정하기 위한 기회를 갖지 못한다. 따라서, 다른 바람직한 실시예에서, 라벨 및 속성은 데이터 콜렉션을 위한 소프트웨어에 의해 유도된다. 라벨 및 속성을 유도하는 단계는 미리 결정된 라벨 및 속성 목록을 위한 잠재적 값이 소프트웨어에 의해 데이터 콜렉션 내에서 발견되는 완전하게 자동화된 과정과 관련된다. 예를 들어, 판매를 위한 아이템 목록에서(예를 들어, 구글의 프루글 시스템(Froogle System)), 미리 결정된 기준(Criteria)을 만족시키는 가격의 금액(Amount)은 그 아이템을 위해 "가격" 속성의 값으로 지정된다. 다른 바람직한 실시예에서, 소프트웨어는 소프트웨어가 속성/값 쌍을 제안하고, 제공자는 속성/값 쌍을 수용하거나 거절하는 과정을 수행한다. 다른 바람직한 실시예에서, html 태그가 스캔되고, 발견된 정보는 태그를 가지는 페이지를 위한 속성 값을 유도하기 위해 사용된다. 예를 들어, 페이지가 다음과 같은 html 코멘트를 포함한다고 가정한다.

<! 현재 가격은 http://www.todayspricesforbigco.com%id=32423490 에 있음 !>

소프트웨어는 지시된 URL로부터 현재 가격을 획득하고, 그 웹 페이지를 위한 가격 속성값을 만들어낸다.

속성 및 라벨이 데이터 아이템과 관련되면(306), 데이터 아이템은 검색될 수 있도록 색인화된다(309). 바람직한 제 1 실시예에서, 속성과 라벨, 및 그 값들이 색인화되지만, 다른 바람직한 실시예에서는 개별적으로 검색되거나 개별적으로 색인화된다.

도 5a는 속성 및 라벨을 저장소(195)에 저장하기 위해 사용되는 데이터 포맷(500)의 예시를 도시한다. 각 아이템은 그 유형에 적합한 특정 속성 및 라벨과 관련된다. 예를 들어, 직업 공고는, 직업 기능 - 제품 관리; 고용주 - ABC 사; 및 직업 유형 - 전문직인 속성을 가진다. 바람직한 실시예에서 속성 및 라벨은 다음 유형의 값을 가질 수 있다.

BOOLEAN

INT

FLOAT

URL

STRING

LOCATION

DATE

DATE RANGE

속성 및 라벨은 저장 장치에 다음의 메타태그(Metatag)에 의해 지시된다.

이름

</end name>

값

</end value>

따라서, 바람직한 실시예에서, 각 속성은 "저널"인 속성 이름 및 "염증에 대한 저널"인 "저널" 속성에 대한 값과 같은 이름/값 쌍이다(도 5b 참조). 각 라벨은 특정 저널이 의학 저널이라는 것을 지시하는 "의학"과 같은 이름만을 가진다(도 5c 참조). 바람직한 실시예에서, 데이터 아이템의 정보 유형도 라벨 중 하나의 이름이다. 따라서, "이벤트 및 활동"이라는 정보 유형을 가진 데이터 아이템도 같은 이름의 라벨을 가진다. 이런 방식으로, 사용자는 데이터 아이템의 정보 유형과 같은 이름을 가진 라벨을 특정함으로써 특정 정보 유형을 가진 데이터를 검색할 수 있다.

도 5d는 정보 유형을 그 속성에 매핑시키기 위한 예시적 데이터 구조를 도시한다. 따라서, 데이터 콜렉션(190)에 있는 아이템이 "제품"이라는 정보 유형을 가지면, 아이템의 속성은 "제품"이라는 정보 유형을 위한 속성 및 속성 유형을 포함하는 도 5c의 데이터 구조에 접근함으로써 결정될 수 있다.

도 5d에 도시된 것처럼, 각 정보 유형은 미리 결정된 속성이다. 속성값은 속성 유형의 값이다. 도 5e는 일부 실질적 값을 도시한다. 따라서, "저널"이라는 정보 유형은 속성 유형이 스트링(String)인 값을 가지는 "저널 이름" 속성 및 널(Null) 값을 가지는 "의학"이라는 라벨을 가진다. 예를 들어, 그러한 속성은 사용자가 특정 저널 제목을 검색할 수 있게 하거나 모든 의학 저널을 검색할 수 있게 해 준다. 유사하게, "제품"이라는 정보 유형은 판매 가능한 특정 제품의 개수를 지시하고 정수의 속성 유형을 가지는 "NumAvail" 속성을 가진다. 모든 속성은 선택적이다. 제공자는 제안된 속성을 채우거나(Populate) 자신만의 속성을 만드는 것을 선택할 수 있다.

도 3b는 수신된 쿼리 용어 또는 용어에 따라서 쿼리 결과를 디스플레이하는 방법을 도시하는 순서도(310)이다. 바람직한 실시예에서, 쿼리 결과는 검색 엔진(185)에 의해 결정된다. 예를 들어, "암 수용체"(402)라는 쿼리(도 4a 참조)는 도 4b에 도시된 것과 같은 속성(404)을 가지는 아이템의 쿼리 결과(406)를 가져온다(312). 상기 언급한 것처럼, 본 발명의 일부 실시예는 이 시점에서 쿼리 결과(406)를 결정하지만 디스플레이하지는 않는다.

쿼리에 대한 쿼리 결과가 결정되면(그리고, 선택적으로 디스플레이되면), 쿼리 결과에 대한 최소한 일부의 속성 이름 및 라벨이 디스플레이된다(322). 데이터 집합(406)의 데이터 아이템은 특정 정보 유형을 가진다. 처음에 디스플레이되는 속성(404)은 쿼리 결과(406)에 있는 데이터 아이템의 정보 유형을 위한 속성의 일부 또는 전체이다. 쿼리 결과는 데이터 아이템을 가지고, 각각의 데이터 아이템은 서로 다른 속성을 가진다. 쿼리 결과의 위쪽에 보이는 속성은 쿼리 결과에서 가장 흔하고, 검색자들에 의해서 가장 많이 클릭되거나 걸러진 속성이다. 예를 들어, "주거(Housing)"라는 쿼리는 침실 및 욕실을 속성으로서 가진 많은 아이템을 가지고, 검색자는 항상 주거라는 쿼리에 대해서 "침실" 및 "욕실" 속성으로 걸러내기를 한다. 그래서 침실 및 욕실은 검색 결과들 위에 맨 윗줄에 나타나야 한다.

도 4b는 쿼리 결과(406), 다수의 속성 및 라벨 이름(404, "저널", "공중보건", "뉴스 소스", "저자")을 도시한다. 각 속성 다음의 숫자는 검색 결과(406)와 관련된 속성을 가진 검색 결과에서 아이템의 개수를 지시한다. 예를 들어, 도 4b에서, 쿼리 결과(406)는 "저널"과 관련된 속성/라벨을 가진 2050 개의 아이템을 포함한다. 따라서, 특정 쿼리 결과와 함께 도시된 속성의 개수 및 주체(Identity)는 쿼리 의존적이고, 나중에 검색 결과를 한정하기 위해 선택되는 속성 및 라벨에 더 의존적이다.

도 3c는 주어진 쿼리 결과(406)에 대해 어떤 속성을 디스플레이할 것인지 결정하는 방법을 도시하는 순서도(340)이다. 최종 사용자가 검색을 수행할 때, q 개의 가장 적절한 결과가 검색 엔진(185)에 의해 결정되고(341), q 개의 가장 적절한 결과에 대한 n 개의 가장 인기있는 속성이 결정된다(342). 상위 n 개의 속성 이름을 위해, 시스템은 상위 m 개의 속성/라벨 값을 결정한다(344). 그런 다음, 히스토그램을 계산하거나, 적절한 결과 집합에서 매칭(Matching)되는 제안(Offer)의 개수를 세어 제안 카운트(Count)를 계산한다(348). q, n, 및 m 값은 모두 설정 가능하다. 이하의 값에 제한되는 것은 아니지만 예시적으로, q는 1,000 개에서 100,000,000 개(q는 특정 쿼리 용어와 매칭되는 모든 결과로 설정될 수도 있음), N은 100 개 부근 및 M은 20 개에서 100개의 범위 내에 있는 값이다.

바람직한 실시예에서, 속성은 히스토그램이 결정되기 전에 표준화된다(346). 특정 구현에서, 소정양의 데이터 소거(Cleanup) 및 표준화는 데이터가 초기에 데이터 콜렉션(190)에 저장될 때 이루어진다. 설명된 실시예에서, 데이터 표준화는 검색되는 쿼리 용어에 기초하여 즉시(On the fly) 이루어진다(예를 들어, 쿼리 용어가 "자동차"일 때 모든 "브랜드" 속성을 "제작"으로 표준화하는 것이 의미있지만, 쿼리가 "핸드백"이면 모든 제작 속성을 "브랜드"로 표준화하는 것이 의미있음). 다른 실시예는 데이터가 데이터 콜렉션(190)으로 수신될 때 더 많은 표준화를 한다. 데이터 표준화는 바람직한 실시예에서 다음과 같이 이루어진다.

1. 보충하기(Stemming) - 예를 들어, 레스토랑 = 레스토랑들

2. 축약하기(Abbreviation) - 예를 들어, sz = 크기

3. 동등한 단위(Units equivalence) - 예를 들어, 무게 = 온스, 파운드 등

4. 철자 수정 시도

보충하기는 변형 및 오기를 데이터 콜렉션(190)으로 끌어오게 함으로써 제공자가 자신의 속성 이름을 특정하는 시스템에서 특히 유용하다. 예를 들어, 보충하기는 사용자가 "저널", "저늘들", "저럴" 등의 속성 이름을 보충된 속성인 "저널들"의 단일 선택으로 필터링하도록 한다.

특정 바람직한 실시예에서, 제공자에 의해 추가된 속성은 확인된 유형이다. 예를 들어, URL, 날짜시간(DateTime), 수(Number), 스트링(String), 위치(Location), Boolean 속성은 그들이 유효한 값을 가지는지 알아보기 위해 확인된다. 일부 실시예는 각각의 URL 값이 활성인지 알아보기 위해 접속을 확인하는데(Ping), 이는 다양한 구현에서 선택적이다. 바람직한 실시예에서, 예를 들어, 구글맵(Google Maps)과 같은 온라인 지도 서비스에 의해 참조되기 위해 위치들은 지리적으로 코딩될 수 있다. 특정 실시예에서, 지오코드될 수 없는 "위치" 속성은 유효하지 않은 것으로 고려된다.

인기있는 속성 및 라벨이 결정되고 디스플레이되면(322; 도 3b 참조), 사용자는 쿼리 결과를 위해 하나 이상의 디스플레이된 라벨 및 속성값을 특정하도록 허용된다(324; 도 3d 참조).

도 4c는 사용자가 도 4b로부터 "저널" 속성을 선택하고 자신의 검색을 한정하기 위해서 영역(408)에 저널의 이름을 입력하기 위해 준비하는 예를 도시한다. 쿼리 용어(402)는 이제 "암 수용체 필터 : 저널"이라는 것을 주목한다. "저널" 속성은 나열된 코어 속성(404)에서 사라졌다.

유사하게, 도 4d에서, 사용자는 제 2 속성인 "년도(410)"를 선택하고, 사용자가 특정 저널 쿼리 용어에서 검색하고자 하는 년도 또는 범위 또는 년도들을 입력한다. 년도 속성은 "년도의 범위" 속성 유형이다. 쿼리 용어(402)가 이제 "암 수용체 필터 : 저널 필터 : 년도"라는 것을 주목한다. "년도" 속성은 나열된 속성(404)로부터 사라졌다. 사용자가 GO 버튼(411)을 선택하면, 선택된 속성이 필터로 사용되어 검색이 다시 수행되고, 도 4e와 같은 화면이 디스플레이된다. 따라서, 사용자는 디스플레이된 쿼리 결과에 대해 하나 이상의 일반적인 속성을 선택할 수 있고, 디스플레이된 속성(또는 라벨)에 따라 초기 검색을 필터링할 수 있다. 사용자가 속성값을 빈 칸으로 두면, 모든 속성값이 매칭된다. 예를 들어, 사용자가 저널 속성을 선택하지만 저널 이름을 입력하지 않으면, 저널 속성을 가진 모든 데이터 아이템(및 유사하게 명명된 속성들)이 쿼리 결과에 대한 가능한 후보로 선택된다. 저널 속성을 가지지 않은 데이터 아이템들은 쿼리 결과에 선택되지 않는다.

도 4d는 검색을 한정하기 위해 사용자가 하나 이상의 속성 또는 라벨을 선택하는 예를 도시한다. 설명된 실시예에서, 다중 라벨 및 속성은 속성 및 라벨(404)의 다중 라벨 및 속성을 클릭함으로써 선택된다. 다른 바람직한 실시예에서는 검색창(402)에 라벨 및 속성이 입력되도록 한다. 예를 들어, 가격 속성이 있으면, 사용자는 쿼리 용어로 다음과 같이 입력할 수 있다.

속성(가격: 150 달러)

상기 쿼리는 가격 속성 및 150 달러 속성값을 가진 현재 쿼리 결과에서 데이터 아이템을 찾는다.

다른 예로, 사용자가 다음과 같이 입력할 수 있다.

속성(가격: 150 달러) 및 라벨(빵상자보다작음)

이 쿼리는 가격 속성, 150 달러 속성값, 및 빵상자보다작음이라는 라벨을 가진 현재 쿼리 결과에서 데이터 아이템을 찾는다. 다른 바람직한 실시예는 다른 적절한 사용자 인터페이스 요소를 사용하여 사용자가 논리적으로 속성 및 라벨을 결합하도록 한다.

도 4e는 도 4d에서 특정된 대로 특정 년도나 년도 범위들의 특정 저널에 한정되는 쿼리 결과를 도시한다. 사용자는 저널 내에서 검색(412)을 계속하기 원하는지 여부 또는 전체 데이터 아이템 콜렉션을 검색(413, 예를 들어, "구글베이스 전체 검색")을 계속하기 원하는지 여부를 결정하도록 허용된다. 이 예에서, 사용자는 영역(414)에서 다수의 라벨("생명공학", "의료", 및 "사진", 이들 각각은 쿼리 결과(406')에서 아이템(30,15 및 6)과 관련됨)의 선택을 제안받는다. 이 예에서, 사용자는 영역(416: 날짜, 저자, 공중보건, 인용)에서 속성을 위한 값을 특정하기 위한 선택을 제안받는다. 사용자는 관련성, 날짜 속성 또는 사용자가 정의하는 어떠한 속성(예를 들어, 가격, 위치 등)에 의해 쿼리 결과(406')를 분류(416)하는 옵션을 제안받기도 한다.

도 4f에서, 사용자는 도 4e의 영역(414)으로부터 "날짜" 속성을 선택하고, 날짜(420)를 입력할 기회가 주어진다. 사용자가 드롭다운(Drop-down) 연산자 "기간(Between)"을 선택할 때, 사용자에게 날짜 범위(도시됨)를 선택할 기회가 주어진다. "날짜" 속성은 나열된 속성(418)으로부터 사라진다. 이 예에서, "저자" 속성은 속성(414)으로부터 사라졌다. 속성이 더 이상 쿼리 및 쿼리 결과와 관련되지 않으면, 그 속성은 사라진다. 사용자가 현재 저널에 의해 필터링하지 않았다는 사실은 사용자가 제한된 아이템 집합에서만 찾고 있다는 것을 가정한다. 검색 및 저자 용어가 다시 나타나도록 하려면 사용자는 Go 버튼을 선택하면 된다.

도 4g는 사용자가 저자 이름(422)을 특정하는 것을 도시한다. 속성 및 라벨은 쿼리 결과에 기초하고 쿼리 결과는 지속적으로 변화하므로, 쿼리가 걸러지면서 새로운 속성 및 라벨이 보이게 된다. 사용자가 Go 버튼(423)을 누를 때, 다른 검색이 수행되고, 사용자에 의해 특정된 속성 및 속성값을 반영하기 위해 쿼리 결과가 더 필터링된다.

이하의 단락에서는 속성 및 라벨을 사용하여 검색 도중 또는 검색을 한정하는 도중에 속성 저장소(195)로의 접근을 설명한다.

저장소(195)를 참조하는 쿼리 및 색인과정은 바람직하게 다음의 연산자를 지원한다.

숫자 - 같음, 사이, 초과, 미만, 숫자 범위 제안

스트링 - 이다(Is), 가지다(Has)

날짜 - 범위, 이전, 이후, 현재

위치 - 내부

저장소(195)는 적어도 다음의 방식으로 쿼리될 수 있다.

-특정 속성 이름-유형 쌍과 매칭되는 모든 아이템을 내게 보낼 것

-속성값의 값에 기초하여 이 아이템들을 분류할 것

-이하의 속성 유형에 따른 분류가 지원됨

-날짜시간

-Number - Int, Float

-스트링

-위치 - 위치를 입력한 사용자로부터의 거리

이 쿼리 능력은 사용자가 다음의 속성 쿼리 유형을 입력하도록 한다.

-특정 이름-유형 쌍을 가진 모든 아이템을 내게 보낼 것

-주어진 이 아이템들을 속성값에 따라 분류할 것(예를 들어, 이벤트_날짜를 가진 모든 아이템을 내게 보내고 오름차순으로 분류된 아이템을 내게 보낼 것)

-특정 이름-유형 속성을 위한 value1 및 value2 사이의 모든 아이템을 내게 보낼 것

예

-요리_유형 속성을 가지고 15 분에서 30 분 사이의 값을 가지는 모든 아이템을 내게 보낼 것

-크기 속성을 가지고 단위 없이 1 및 15의 값을 가지는 모든 아이템을 내게 보낼 것

-이벤트_날짜 속성을 가지고 오늘 이전의 값을 가지는 모든 아이템을 내게 보낼 것

-발행_날짜 속성을 가지고 1925 년의 값을 가지는 모든 아이템을 내게 보낼 것

이하의 연산자가 지원된다.

-숫자의 경우 -int, float

-미만

-초과

-사이

-날짜시간의 경우 -현재

-이전

-이후

-사이

-아이템 점수

현재 아이템이 채점되는 2 개의 주요한 신호가 있다.

-쿼리 의존 순위 - 주로 IR 점수

-쿼리 독립 순위 - 페이지 순위 및 아이템 순위의 복합

페이지 순위는 제공자의 웹사이트 페이지 순위이다. 페이지 순위는 아이템이 데이터 콜렉션(190)에서 호스트(Host)되는 경우 및/또는 아이템이 다른 아이템들에 링크되지 않거나 연결되지 않은 경우에는 존재하지 않는다.

아이템 순위는 다수의 인자(Factor)에 의해 결정될 수 있다. 두 가지 주요한 신호는 다음과 같다.

-제공자 특정 신호(예를 들어, 등급)

-제안 특정 신호(예를 들어, desc의 길이, 속성 및 라벨의 개수, 사진 등)

-아이템 순위는 다음의 신호들에 의해 정의될 수 있다.

-desc 길이

-제목의 길이

-라벨의 개수

-속성의 개수

-사진

-제안이 스팸으로 보고된 횟수

-제공자의 등급

-제안의 새로움(Recency)

아이템은 쿼리 의존 순위*쿼리 독립 순위로 채점된다.

기본 분류(Default Sort)에 대하여, 상기 순위가 기본 분류이다.

바람직한 실시예에서, 특정 파라미터가 시스템에 설정될 수 있다. 이 파라미터는 제공자 당 아이템의 최대 개수를 포함한다. 이는 특정 제공자에 의한 페이지의 혼잡을 방지한다.

사용자가 검색을 한정하기 위해 속성 및/또는 라벨을 선택할 때, 시스템은 라벨, 제목, 설명 및 속성값을 검색한다. 속성 이름도 완성된 이름처럼 검색 가능해야만 한다. 구(Phrase)는 멀리 떨어져 있는 단어들과 비교하여 높은 가중치가 부여된다. 라벨은 제목에 비해 높은 가중치가 부여되고, 제목은 설명보다 훨씬 더 높은 가중치가 부여된다. 속성값은 라벨과 동일한 정도로 중요하다. 각 제공자에 의한 소매상 모집(Merchant Crowding)은 개인 제공자로부터 아이템의 페이지 수가 검색 결과로 디스플레이되거나 디스플레이되지 않는지 여부를 규제하기 위해 사용자에 의해 온되거나 오프된다. 수행된 검색에 의존하여, 소매상 모집은 바람직할 수도 있고, 바람직하지 않을 수도 있다.

바람직한 실시예에서, 시스템은 동일하거나 유사한 유형의 다른 아이템과 관련된 속성에 기초하여 새로운 아이템의 특정 유형의 구조를 정의한다(예를 들어, "직업들" 정보 유형의 대부분의 아이템이 직업 기능, 직업 유형 및 고용주의 속성을 가지고 있다면, "직업" 정보 유형의 데이터 아이템을 위한 공통 속성 구조는 직업 유형, 고용주 및 직업 기능이 되도록 디폴트(default) 된다). 검색자 및 다른 프로그램은 "고용주가 ABC 사이고 직업 유형이 제품 관리인 모든 직업을 내게로 보낼 것"과 같은 쿼리로 데이터 집합을 쿼리할 수 있다.

본 발명에 설명된 예는 사람인 사용자를 언급하더라도, 본 발명의 다른 실시예는 인공 지능 소프트웨어 프로그램과 같은 사람이 아닌 사용자, 또는 웹을 통해 통신하는 사람이거나 사람이 아닌 실체(Entity)와 동작하도록 설계될 수 있음을 이해할 것이다. 사람이 아닌 사용자가 소프트웨어 프로그램이면, 상기 설명한 것처럼 결과 및 속성을 디스플레이할 필요가 없다. 대신에, 그러한 구현은 쿼리 결과를 한정하는데 사용될 수 있는 잠재적 속성과 통신할 뿐이다. 그러한 실시예에서, 사람이 아닌 인공 지능은 선택해야 할 다수의 속성에 의해 위축되기 않기 때문에, 더 많은 속성의 옵션이 디스플레이될 수 있다. 그러한 실시예에서, 히스토그램을 결정하는 과정과 같은 방법의 구성 요소는 필요하지 않거나, 속성 선택의 순위를 매기고 가능한 속성 선택의 개수를 제한하지 않기 위해서만 사용될 수 있다.

주기적으로, 구조화된 데이터(190)에서 다양한 정보 유형을 위한 코어 속성이 업데이트될 필요가 있음이 이해될 것이다. 데이터가 구조화된 데이터 콜렉션에 추가되면서, 처음에는 인기가 없었던 특정 속성이 인기를 얻을 수 있다. 예를 들어, 정수(Integer)의 속성 유형을 가지며 출연진(Cast) 사진의 출처인 텔레비전 쇼의 어떤 시즌을 특정하는 "시즌(Season)" 속성은 "TV 쇼" 정보 유형으로 초기 코어 속성에 의해 처음에는 고려되지 않지만, 더 많은 출연진 사진이 데이터 콜렉션에 추가되면서 시즌 속성은 인기를 얻게 될 수 있다. 일부 실시예에서, 코어 속성은 스팸 필터를 통과한 후에 인기 및 시즌에 기초하여 자동 업데이트 되기도 한다.

도 3e는 제공자가 제공한 새로운 속성이 정보 유형을 위해 코어 속성에 추가되어야만 하는지를 결정하기 위해 주기적으로 수행되는 방법(350)을 도시한다. 아이템 정보 유형을 위한 속성의 코어 그룹은 제공자가 새로운 정보 유형의 아이템을 추가할 때마다 자동으로 제안되는 속성이다. 바람직한 실시예에서, 제공자가 자신의 방식을 디스플레이된 속성에 강제하기 위해 속성을 스팸(Spam)할 가능성을 감소시키도록 코어 속성만이 제안된다. 정보 유형 각각을 위해, 본 방법은 그 정보 유형을 위해 사용자가 추가한 가장 인기 있는 속성만을 살피고(322), 그 정보 유형에 대해 가장 인기 있는 속성을 코어 속성으로 승급시킨다(Promote).

어떤 속성이 코어 속성으로 승급되는지 결정하기 위해 사용되는 "가장 인기있음"은 서로 다른 실시예에서 다르게 정의된다. 예를 들어, 가장 인기있음은 예를 들어, 일주일 또는 한 달과 같은 미리 결정된 시간 주기 동안 사용자에 의해 가장 자주 선택(352)된, 코어 속성에 없는 속성일 수 있다. 다른 예로서, 가장 인기있음은 미리 결정된 시간 주기 동안 쿼리 결과에서 가장 자주 나타나는 데이터 아이템을 가진, 코어 속성에 없는 속성일 수 있다. 또 다른 예로서, 가장 인기있음은 미리 결정된 시간 주기 동안 대규모의 제공자 데이터에 나타나는, 코어 속성에 없는 속성일 수 있다. 가장 인기있음은 코어 속성에 추가되며 검색을 한정하는데 유용한 속성을 만들어 낸다면 어떠한 적절한 방식으로도 결정될 수 있다.

예를 들어, 제공자는 블로그에서 언급되는 기사(Article)를 표시하기 위해 기사의 아이템 정보 유형을 위한 "블로그됨(Blogged)" 속성을 추가하기 시작할 수 있다. 그러한 속성은 URL 속성 유형을 가지고, 블로그의 URL은 아이템이 어디에서 언급되었는지 표시해준다. 유일한 제공자 또는 사용자의 임계치(354) 숫자가 정보 유형을 위해 특정한 새로운 속성을 사용하면, 속성은 그 정보 유형을 위한 속성의 코어 그룹에 추가된다(356). 바람직한 실시예에서, 임계치 값은 시스템을 사용하는 제공자의 전체 숫자에 기초한다. 이는 2~3 개의 작은 값에서 시작하여 큰 숫자로 증가될 것이다. 인기 있는 라벨을 코어 라벨 집합에 추가하기 위해 라벨의 경우에도 유사한 방법이 수행된다. 바람직한 실시예에서, 승급된 속성은 사람에 의해 또는 적절한 소프트웨어 또는 하드웨어로 구현된 방법에 의해 완전함(Sanity)이 확인된다.

상기 단락에서는 구조화된 데이터 콜렉션(190)에 입력되는 데이터를 검색하고 업데이트하기 위한 방식을 일반적으로 설명하였다. 이하의 단락에서는 제공자가 구조화된 데이터 콜렉션(190)에 데이터를 입력하거나 추가할 수 있는 방식에 대해서 설명한다. 바람직한 실시예에서, 제공자는 또한 자신의 데이터를 위한 새로운 속성을 특정할 수 있다

도 6a 내지 6e는 제공자가 데이터 콜렉션의 아이템을 어떻게 편집할 수 있는지를 도시하는 예시적 스크린 샷이다. 제공자는 데이터 콜렉션(190)에 콘텐츠를 추가하거나 추가할 수 있는 자이다. 설명된 실시예에서, 데이터 콜렉션(190)은 개인, 비영리 집단, 또는 회사와 같은 하나 이상의 제공자에 의해 소유된 데이터이다. 본 실시예는 그러한 사용자가 웹을 통해 자기들의 고유한 구조화된 데이터 콜렉션(예를 들어, 데이터베이스)을 셋업하고 채우도록 하고, 웹 또는 유사한 네트워크를 통해 콜렉션을 검색가능하도록 만들어준다. 제공자는 다른 사람에 의해 데이터가 검색되도록 허용하는 수수료 또는 대가로서 중앙 저장소에 데이터를 저장하려고 하는 것이 고려된다. 그러한 경우에, 데이터 콜렉션은 본 발명에 설명된 일부 또는 모든 기능을 포함한 버전의 구글 브라우저 또는 구글 데스크탑 검색 엔진과 같은 웹 또는 네트워크 기반 브라우저를 통해 검색될 수 있다.

도 6a 내지 6e는 제공자가 데이터를 편집 및 시스템에 입력하도록 해주는 사용자 인터페이스를 도시하는 예시적 스크린 샷이다.

도 6a는 제공자가 데이터 콜렉션(190)의 데이터 아이템을 보고 편집할 수 있도록 하는 사용자 인터페이스(600)를 도시한다. 사용자 인터페이스는 데이터 콜렉션(190)에 아이템을 추가하기 위해서도 사용될 수 있다. 영역(602)은 데이터 콜렉션(190)에 있는 아이템의 일부 목록을 포함한다. 이 예에서, 이 목록은 아이템 제목(601), 아이템 유형(605,정보 유형이라고도 함), 상태(603), 만료 기한, 임프레션(Impression) 횟수(아이템이 디스플레이된 횟수), 대상을 클릭한 횟수, 및 사용자 클릭 비율, 검색 결과에서 아이템이 클릭된 횟수를 포함한다. 예에서, 데이터 콜렉션의 모든 아이템의 부분 집합이 영역(602)에 도시되지만, 제공자는 자신의 개인적 데이터 콜렉션(620)을 검색하거나 전체 데이터 콜렉션(622)을 검색할 수도 있다. 제공자는 비활성 아이템(616) 또는 벌크 업로드 파일(618)을 볼 수도 있다. 데이터 아이템 각각은 관련 "편집" 링크(619)를 가진다. 바람직한 실시예에서, 제공자는 자신의 고유한 데이터 아이템만을 편집할 수 있다. 영역(604)은 제공자가 현존하는 정보 유형(이벤트 및 활동, 주거 등)을 보여주는 드롭다운 메뉴와 같은 선택 디바이스를 디스플레이하도록 한다. 제공자가 정보 유형을 선택하면, 제공자는 자신의 데이터를 위해 영역(606)에 정보 유형의 설명을 추가할 수 있다.

도 6b는 제공자가 데이터 콜렉션(190)의 데이터 아이템을 보고 편집(610)할 수 있도록 하는 사용자 인터페이스를 도시한다. 아이템은 "뉴스 및 기사" 정보 유형을 가진다. 제공자가 도 6a의 영역(602)에서 데이터 아이템을 선택하면, 그 아이템의 정보가 영역(611)의 필드에 디스플레이된다. 하지만, 이 예에서, 제공자가 아이템을 선택하지 않았다면, 제공자가 새로운 데이터 아이템을 입력하는 것은 자유이다. 이 예에서, "뉴스 및 기사" 정보 유형(610)은 쿼리 결과에 디스플레이되기 위한 제목, 사진, 설명 및 링크(예를 들어, URL; 614)와 같은 필드를 포함한다.

또한, 도 6b의 사용자 인터페이스는 제공자가 아이템의 속성 및 라벨도 편집할 수 있도록 한다. 주목할 것은, 정보 유형 각각이 속성과 관련되지만, 특정 유형의 데이터 아이템 모두가 그 정보 유형을 위해 모든 가능한 속성값을 가지는 것은 아니라는 점이다. 이 예에서, 참조 번호 612에 의해 도시된 것처럼, 제공자는 아이템 수량 "1 개"가 사용 가능하거나 존재함을 표시한다. 이 아이템에 대한 저자 또는 뉴스 소스 속성을 위해 특정된 값은 없다. 각각의 속성은 "텍스트" 속성 유형을 가진다. 제공자가 개별적인 데이터 아이템의 속성값을 추가하는 것은 자유이다. 제공자는 영역(613)을 사용하여 속성을 추가할 수도 있다. 이 경우, 제공자는 속성 이름 및 속성값을 추가할 수 있다.

제공자는 영역(618)의 연락처(Contact) 정보와 관련된 속성값을 제공할 수 있다. 제공자는 영역(619)의 위치 정보와 관련된 속성값을 제공할 수 있다.

제공자는 라벨을 영역(619)의 아이템에 추가할 수 있다. 특정 실시예에서, 정보 유형은 기본 속성 이름이다. 이 경우, 정보 유형은 뉴스 및 기사이고, 이것이 라벨이기도 하다.

도 6c는 제공자가 데이터 콜렉션(190)의 데이터 아이템을 보고 편집(610)할 수 있도록 하는 도 6b의 사용자 인터페이스를 도시한다. 이 예에서, 제공자는 제공자가 정의한 새로운 속성(613)을 위한 이름 및 값을 추가할 수 있다. 기본 속성 유형은 "텍스트"이지만, 제공자는 숫자 단위, 숫자, 날짜 범위, 큰 텍스트, URL, Boolean, 및 위치와 같은 다른 속성 유형을 선택할 수 있다.

도 6d는 제공자가 데이터 콜렉션(190)의 데이터 아이템을 보고 편집(610)할 수 있도록 하는 사용자 인터페이스를 도시한다. 아이템은 "제품" 정보 유형(630)을 가진다. 제공자가 도 6a의 영역(602)에 있는 데이터 아이템을 선택하면, 그 아이템의 정보가 영역(611)의 필드에 디스플레이된다. 하지만, 이 예에서, 제공자가 아이템을 선택하지 않았으면, 제공자가 사용자 인터페이스(630)를 사용하여 새로운 아이템을 입력하는 것은 자유이다. 이 예에서, "제품" 정보 유형은 쿼리 결과에 디스플레이되기 위한 제목, 사진, 설명 및 링크(634: 예를 들어, URL)와 같은 필드를 포함한다.

도 6d의 사용자 인터페이스는 제공자가 아이템의 속성 및 라벨도 편집할 수 있도록 한다. 주목할 것은, 정보 유형 각각이 속성과 관련되지만, 특정 정보 유형의 데이터 아이템 모두가 그 정보 유형을 위해 모든 가능한 속성값을 가지는 것은 아니라는 점이다. 이 예에서, 참조 번호(632)에 의해 도시된 것처럼, 제공자는 아이템 당(예를 들어, 파운드 당 또는 다스 당과 비교됨) 가격이 150 달러임을 표시한다. 수량이 "1 개"임이 특정된다. 가격 유형은 제공자가 설정한 가격 유형이다(예를 들어, 최적 제안, 흥정 가능, 고정됨 등). 이 아이템에 대한 가격 옵션, 브랜드, 조건, 및 제품 유형에 대해 특정된 값은 없다. 그러한 속성 각각은 "텍스트" 속성 유형을 가진다. 이 예에서, 제공자는 자신이 특정한 속성을 위한 속성 유형을 변경할 수 있다. 제공자가 개인적인 데이터 아이템의 속성값을 추가하는 것은 자유이다. 제공자는 영역(613)을 사용하여 속성을 추가할 수도 있다. 이 경우, 제공자는 속성 이름 및 속성값을 추가할 수 있다.

이 실시예에서, 제공자가 추가한 속성은 현재 정보 유형의 모든 아이템에 추가된다. 예를 들어, 새로 추가된 속성(613)이 일단 정의되면, "제품" 유형을 가진 제공자의 모든 아이템에 새로 추가된 속성(613)이 주어진다. 각 아이템을 위한 값은 보통 개별적으로 추가된다. 특정 실시예에서 제공자는 특정된 정보 유형의 모든 아이템에 대하여 값을 특정할 수 있다. 상기한 것처럼, 새로운 속성이 코어 속성 집합으로 진급하는 것도 가능하다. 다른 실시예에서, 새로운 속성이 정보 유형의 모든 아이템에 항상 추가되지는 않는다. 다른 실시예에서, 제공자들은 규정된 제공자들의 그룹이 동일한 속성을 갖는 것에 대하여 동의할 수 있고, 따라서 한 제공자가 속성을 추가하면, 그 그룹의 나머지 제공자들도 동일한 속성을 갖게 된다.

제공자는 영역(618)의 연락처 정보와 관련된 속성값을 제공할 수 있다. 제공자는 영역(619)에 위치 정보와 관련된 속성값을 제공할 수 있다. 제공자는 영역(638)에 지불 방법과 관련된 속성값을 제공할 수 있다.

제공자는 영역(616)의 아이템에 라벨을 추가할 수 있다. 특정 실시예에서, 정보 유형은 기본 속성 이름이다. 이 경우, 정보 유형은 제품이고, 이는 라벨이기도 하다. 이 실시예에서, 제공자가 추가하는 라벨은 현재 유형의 아이템 모두에 추가되지는 않는다(라벨이 정보 유형인 경우는 제외함). 상기한 것처럼, 새로운 라벨이 코어 라벨 집합에 진급하는 것도 가능하다. 다른 실시예에서, 새로운 라벨이 정보 유형의 모든 아이템에 항상 추가된다.

도 6e는 제공자가 데이터 콜렉션(190)의 데이터 아이템을 보고 편집(630)할 수 있도록 하는 도 6d의 사용자 인터페이스를 도시한다. 이 예에서, 연락처, 지불, 및 위치는 제품 정보 유형의 모든 속성이다. 이 속성은 복합 유형(정수 또는 단순한 스트링이 아님)을 가지는 속성이다. 이 예에서, 제공자는 "제품" 정보 유형의 아이템을 위해 연락처(618)와 관련된 값을 추가할 수 있다. 이 경우, 제공자는 별명, 전화 번호, 이메일 주소(제공자 정보의 데이터베이스로부터 가져온 잠재적 값, 도시되지 않음)의 일부 또는 전부를 특정한다. 이 예에서, 제공자는 "제품" 정보 유형의 아이템을 위해 지불(638)과 관련된 값을 추가할 수 있다. 이 경우, 제공자는 지불 방법 및 노트의 일부 또는 전부를 특정한다. 이 예에서, 제공자는 "제품" 정보 유형의 아이템을 위해 위치(619)와 관련된 값을 추가할 수 있다. 이 경우, 제공자는 텍스트 노트(예를 들어, "캘리포니아, 프리몬트")의 일부 또는 전부를 특정한다. 이 실시예에는, 고객이 이 위치 및 배달 반경으로부터 픽업(Pickup)할 수 있는지 여부를 표시하는 체크박스도 있다.

이 예에서, 연락처, 지불, 및 위치 값은 각 아이템마다 별도로 입력된다. 제공자가 추가하는 값은 현재 정보 유형의 아이템 모두에 추가되지는 않는다. 예를 들어, 이 경우, "제품" 정보 유형의 모든 제공자 아이템이 도 6e에 도시된 연락처, 지불, 및 위치 값에 주어지는 것은 아니다. 각 아이템을 위한 값은 보통 개별적으로 추가된다. 특정 실시예는 제공자가 특정 정보 유형의 모든 아이템을 위한 값도 특정할 수 있도록 한다. 예를 들어, 지불 정보는 제공자의 모든 "제품"에 대해서 동일할 수 있다.

후원자(Promoter)는 도 6의 사용자 인터페이스(UI)를 통해, 또는 도 7 및 도 8에 도시된 벌크 업로드 방법을 통해 아이템을 입력할 수 있다.

도 7은 벌크 업로드 파일을 등록하기 위한 사용자 인터페이스를 도시하는 예시적 스크린 샷(700)이다. 벌크 업로드 파일은 데이터 콜렉션(190)을 만들거나 그에 추가하기 위해 사용된다. 이 예에서, 모두 동일한 정보 유형인 아이템의 플랫 파일(flat file)이 추가된다. 이 예에서, 파일 이름(712)은 "지역 조사(Local Inventory)"이다. 제공자는 미리 결정된 정보 유형 또는 개인화된 정보인 데이터 유형(714)을 선택한다. 제공자는 데이터의 텍스트 스트링을 위한 언어(716)를 선택한다. 제공자가 "벌크 업로드 파일 등록" 버튼(718)을 선택할 때, 파일 이름(712)을 가진 파일이 등록되고 제공자는 파일을 업로드 할 수 있게 된다. 제공자는 웹 기반 업로드 인터페이스를 사용하거나 FTP(File Transfer Protocol) 또는 RSS와 같은 다른 메커니즘을 사용하여 파일을 업로드할 수 있다.

도 8a는 벌크 업로드되는 탭제한(Tab-delimited) 파일을 위한 포맷(801)을 도시한다. 다음의 내용은 벌크 업로드 파일을 위한 포맷 요구사항이다.

-탭제한 일반 텍스트

-파일의 첫번째 줄은 헤더일 것 - 반드시 속성 이름을 포함하고(이하에 기술함), 탭에 의해 나누어질 것

-한 줄에 하나의 아이템; 각 속성은 탭에 의해 나누어질 것

-라인의 마지막에 트레일링(Trailing) 탭을 가지면 안됨

-파일은 반드시 LATIN1 또는 UTF-8 인코딩으로 저장될 것. LATIN1의 부분 집합인 ASCII도 가능함

-링크와 이미지 URL은 충분히 검증된 것이어야만 함. 즉, 예를 들어, http://www.example.com/image.gif와 같이 http:// 부분을 반드시 포함할 것

-탭, 복귀(Carriage Return), 또는 줄 내림 문자(New Line Character) - 이들 중 하나라도 속성에 나타나면, 그 아이템은 디스플레이할 수 없음

-HTML 태그, 주석, 및 확장 문자열(Escape Sequence) - HTML은 벌크 업로드로부터 제거되지 않지만, 최적의 모습을 위해 HTML을 포함하지도 않음

바람직한 실시예에서, 데이터 아이템은 속성도 포함하는 업로드된 파일의 일부이다. 다른 바람직한 실시예에서, 데이터 아이템 및 속성은 어떤 속성값이 어떤 데이터 아이템에 속하는지 명확하게 하기 위해 구성되는 별개의 파일로 업로드된다.

도 8b는 벌크 업로드 파일을 만들기 위해 제공자에 의해 사용되는 예시적 방법의 순서도(800)이다. 제공자는 사람이거나, 하드웨어 또는 소프트웨어일 수 있다.

요소 802: 스프레드시트(Spreadsheet) 프로그램에서 새 파일을 오픈함

설명된 방법은 벌크 업로드 파일을 만들기 위해 마이크로소프트의 엑셀과 같은 스프레드시트 프로그램을 사용한다. 마이크로소프트의 엑셀과 같은 스프레드시트 프로그램을 사용하여 벌크 업로드 파일을 쉽게 만들고 이를 적절한 포맷으로 전환할 수 있다. 적절하게 포맷된 파일을 만들기 위해 다른 방법들도 사용될 수 있다.

요소 804: 헤더 가로줄(Row)을 만듦

예로서, 제품 벌크 업로드를 위한 헤더 가로줄은 도 8c의 가로줄(832)처럼 생겼다. 제공자가 제출하고자 하는 아이템의 정보 유형(도 7의 714 참조)에 따라 벌크 업로드의 세로줄 각각을 특정한다. 스프레드시트의 첫 번째 가로줄(832)에서, 제공자가 자신의 아이템을 설명하기 위해 포함시키고자 하는 각 속성의 이름을 입력한다. 이것이 헤더 가로줄이다. 헤더 가로줄의 콘텐츠는 제출된 정보의 정보 유형, 및 제공자가 정의된 정보 유형을 전송했는지 또는 자신이 직접 창조한 정보 유형을 전송했는지 여부에 의존한다.

개인화 정보 유형:

벌크 업로드는 어떤 유형의 정보도 제출하도록 사용될 수 있다. 제공자가 자신의 고유한 정보 유형을 전송하면, 제공자는 미리 정의된 속성의 어떠한 조합도 사용할 수 있다. 바람직한 실시예에서, 제공자는 미리 정의된 속성을 사용하도록 강력하게 권고된다. 제공자는 개인화 속성을 개수 제한 없이 사용할 수도 있다. 제공자는 자신의 아이템을 가장 잘 설명하는 속성 집합을 골라야 한다.

정의된 정보 유형:

제공자는 정의된 정보 유형 중 하나를 위해 벌크 업로드를 전송할 수 있다. 제공자는 자신의 벌크 업로드에 정의된 정보 유형을 포함시키도록 강력하게 권고된다. 정의된 정보 유형은 쿼리를 검색하기 위해 더 정확하게 아이템이 매칭되도록 한다. 제공자가 더 많은 정보를 줄수록, 사용자가 아이템을 찾기가 쉬워진다. 바람직한 실시예에서, 제공자는 제공자의 아이템이 완료된 검색의 중요한 부분에 나타날 수 있도록 하는 권고된 속성을 포함시켜야만 한다.

요소 806: 아이템 정보를 입력함

각 가로줄(834)에서, 제공자는 자신의 데이터 콜렉션의 아이템을 위한 정보를 입력한다. 각 정보는 그 정보가 속한 세로줄의 헤더를 반영해야만 한다(예를 들어, 제품의 가격은 "가격" 헤더 아래로 가야만 함). 각 가로줄은 가로줄 당 하나의 아이템만 포함한다. 도 8c를 참조한다.

요소 808: 벌크 업로드를 탭제한이 있는 보통(Plain) 텍스트로 전환함

이전에 등록된 파일 이름을 사용하여 스프레드시트를 탭제한이 있는 텍스트(.txt) 파일로 전환한다(도 7 참조). 제공자가 모든 아이템을 스프레드시트에 입력한 후에, 제공자는 탭제한이 있는 텍스트(.txt) 포맷으로 스프레드시트를 저장한다. 등록된 파일 이름은 차기 업로드를 위해 재사용될 수 있다. 업로드된 파일이 등록되지 않은 이름을 가지면, 파일에 있는 아이템은 데이터 콜렉션(190)에 추가되지 않을 것이다. 바람직한 실시예에서, 데이터 콜렉션(190)에 아이템이 유지되는 것을 확실히 하기 위해서 적어도 30 일마다 한 번씩 업데이트된 벌크 업로드가 전송되어야만 한다.

요소 810: 파일을 업로드함

도 8d는 파일을 업로드하기 위한 사용자 인터페이스(840)를 도시한다.

요소 812: 벌크 업로드의 에러(Error)를 확인함

제공자가 벌크 업로드를 전송한 후에, 제공자는 중앙 웹 사이트에 로그인하여 벌크 업로드 상태를 볼 수 있다. 결과가 '성공'으로 나열되면, 벌크 업로드는 변경될 필요가 없다. 실패이면, 제공자는 에러(들)를 어떻게 수정해야 하는지에 관한 정보를 보기 위해 벌크 업로드의 파일 이름을 클릭할 수 있다.

벌크 업로드가 업로드된 후에, 파일은 아이템, 속성, 및 라벨을 데이터 콜렉션(190) 및 도 5의 데이터 구조에 추가하기 위해 처리된다. 업로드가 승인되면, 이후에 동일한 파일 이름의 어떠한 업데이트도 자동으로 처리된다.

본 발명은 상기한 것처럼 다수의 실시예와 함께 설명되었지만, 다양한 수정이 본 발명의 범위 내에서 만들어질 수 있다. 예를 들어, 특정한 바람직한 실시예는 유효하지 않거나 "스팸" 속성 및 라벨을 탐지하기 위한 방법 및 시스템을 포함한다. 제공자가 데이터 아이템을 검색의 가장 위에 오도록 하는 자신의 데이터에 속성을 추가하는 것은 바람직하지 못하다. 그러한 속성을 피하기 위해 사용된 일부 방법은 블랙리스팅(Blacklisting), 특정 히스토그램 분포 등을 포함한다.

다른 바람직한 실시예에서 디스플레이된 상위 속성 및 라벨은 단순히 속성 키-유형 튜플(Tuple) 및 라벨의 인기에 기초하여 결정되는 것이 아니고 값의 분포에 기초하여 결정된다(분포가 이산적(Discrete)일수록 더 좋고, 스큐(Skew)가 클수록 더 좋음. 예를 들어, 속성을 위한 5 개의 인기있는 값이 균등하게 분포된 50 개의 값보다 좋음). 예를 들어, 색깔이 속성이고, 상위 색깔이 빨간색, 파란색 및 녹색이면, 이들은 걸러내기를 하기에 좋은 속성이다. 한편, 각각의 3 번 발생하는 색깔에 대해 100 개의 값을 가지는 것은 도움이 되지 않는다.

다른 바람직한 실시예는 속성, 아이템 순위/각 제안의 제안 순위를 사용하는 제공자의 수에 기초하여 복잡한 신뢰도 점수를 계산한다.

다른 바람직한 실시예는 어떤 속성을 사용자에게 디스플레이할 것인지 결정하기 위해 사용자로부터의 클릭 신호를 사용한다. 속성 및 라벨은 인기 순위로 정의된 무엇인가에 의해 채점된다.

PR = 쿼리 결과에서의 인기*그 특정 쿼리에 대한 CTR

다른 바람직한 실시예에서, 사용자의 ALWAYS2 속성이 특정 쿼리를 제한하면 쿼리 결과에 미리 적용된 제한을 보여준다(예를 들어, 아이팟은 90%의 경우에 가격 및 위치에 대해 항상 제한되고, 사용자가 아이팟을 입력할 때 시스템은 미리 가격 및 위치를 제한함).

따라서, 본 발명의 개시는 예시적인 것을 의도한 것이고, 본 발명의 핵심을 한정하지 않으며, 본 발명의 핵심은 이하의 특허 청구범위에 기술된다.

Claims

컴퓨터 구현 방법으로서,

콜렉션(collection) 내 데이터 아이템들로부터 속성들을 추출하는 단계;

클라이언트 디바이스를 통해 검색 엔진(search engine)과 상호 작용하는 사용자로부터 검색 쿼리를 수신하는 단계;

데이터 아이템들의 상기 콜렉션으로부터 제1 데이터 아이템들― 상기 제1 데이터 아이템들은 상기 검색 쿼리를 충족시키고, 상기 제1 데이터 아이템들은 상기 제1 데이터 아이템들로부터 추출된 제1 속성들을 집합적으로 구비함―에 대한 선택을 수신하는 단계;

제1 데이터 아이템들로부터 추출된 제1 속성 각각에 대한 속성 빈도(attribute frequency)―상기 속성 빈도는 상기 검색 엔진의 이전 사용자들이 검색 결과들을 신속하게 좁히기 위해 미리 결정된 시간 기간 동안에 상기 제1 속성들 각각을 선택한 개별적 빈도임―를 결정하는 단계;

가장 높은 개별적 속성 빈도를 갖는 상기 제1 속성들을 코어 그룹 속성(core group of attributes)―상기 코어 그룹 속성은 모든 상기 제1 속성보다 적은 속성들은 포함함―으로서 선택하는 단계;

2개 이상의 상기 제1 데이터 아이템들 각각에 대한 개별적 참조(a respective reference) 및 상기 코어 그룹의 속성 각각에 대한 개별적 표시(a respective representation)를 포함하는 검색 엔진 결과 페이지를 상기 클라이언트 디바이스에 출력하는 단계;

쿼리 한정(query refinement)을 수신하기 위한 검색 창을, 상기 코어 그룹의 하나 이상의 속성의 표시에 대한 사용자 선택에 응답하여 제공하는 단계; 및

상기 검색 쿼리와 상기 쿼리 한정을 충족시키는 제2 데이터 아이템들에 대한 선택을 수신하는 단계를 포함하는 방법.
청구항 1에 있어서,

상기 코어 그룹의 모든 속성들보다 적은 속성들의 표시에 대한 사용자 선택을 수신하는 단계;

2개 이상의 상기 제2 데이터 아이템들 각각에 대한 개별적 참조를 포함하는 제2 검색 엔진 결과 페이지를 상기 클라이언트 디바이스에 출력하는 단계를 더 포함하는 방법.
청구항 1에 있어서, 상기 콜렉션에 대한 웹 탐색(web crawl)을 실행하는 단계를 더 포함하고, 상기 콜렉션은 상기 데이터 아이템들, 및 이 데이터 아이템 각각의 정보 유형을 설명하는 연관된 속성들을 저장하는 방법.
명령어들을 포함하는 컴퓨터 프로그램 제품이 저장된 컴퓨터 판독 가능 매체로서, 상기 명령어들은 실행되었을 때 컴퓨터가 동작들을 수행하게 하고, 상기 동작들은

콜렉션 내 데이터 아이템들로부터 속성들을 추출하는 단계의 동작;

클라이언트 디바이스를 통해 검색 엔진과 상호 작용하는 사용자로부터 검색 쿼리를 수신하는 단계의 동작;

데이터 아이템들의 상기 콜렉션으로부터 제1 데이터 아이템들― 상기 제1 데이터 아이템들은 상기 검색 쿼리를 충족시키고, 상기 제1 데이터 아이템들은 상기 제1 데이터 아이템들로부터 추출된 제1 속성들을 집합적으로 구비함―에 대한 선택을 수신하는 단계의 동작;

제1 데이터 아이템들로부터 추출된 제1 속성 각각에 대한 속성 빈도―상기 속성 빈도는 상기 검색 엔진의 이전 사용자들이 검색 결과들을 신속하게 좁히기 위해 미리 결정된 시간 기간 동안에 상기 제1 속성들 각각을 선택한 개별적 빈도임―를 결정하는 단계의 동작;

가장 높은 개별적 속성 빈도를 갖는 상기 제1 속성들을 코어 그룹 속성―상기 코어 그룹 속성은 모든 상기 제1 속성보다 적은 속성들은 포함함―으로서 선택하는 단계의 동작;

2개 이상의 상기 제1 데이터 아이템들 각각에 대한 개별적 참조 및 상기 코어 그룹의 속성 각각에 대한 개별적 표시를 포함하는 검색 엔진 결과 페이지를 상기 클라이언트 디바이스에 출력하는 단계의 동작;

쿼리 한정을 수신하기 위한 검색 창을, 상기 코어 그룹의 하나 이상의 속성의 표시에 대한 사용자 선택에 응답하여 제공하는 단계의 동작; 및

상기 검색 쿼리와 상기 쿼리 한정을 충족시키는 제2 데이터 아이템들에 대한 선택을 수신하는 단계의 동작을 포함하는 컴퓨터 판독가능 매체.
청구항 4에 있어서,

상기 코어 그룹의 모든 속성들보다 적은 속성들의 표시에 대한 사용자 선택을 수신하는 단계의 동작;

2개 이상의 상기 제2 데이터 아이템들 각각에 대한 개별적 참조를 포함하는 제2 검색 엔진 결과 페이지를 상기 클라이언트 디바이스에 출력하는 단계의 동작을 더 포함하는 컴퓨터 판독 가능 매체.
시스템으로서,

하나 이상의 컴퓨터와;

상기 하나 이상의 컴퓨터에 접속되며, 명령어들을 포함하는 컴퓨터 판독 가능 매체를 포함하고,

상기 명령어들은 상기 하나 이상의 컴퓨터에 의해 실행되었을 때, 상기 하나 이상의 컴퓨터가 동작들을 수행하게 하고, 상기 동작들은

콜렉션 내 데이터 아이템들로부터 속성들을 추출하는 단계의 동작;

클라이언트 디바이스를 통해 검색 엔진과 상호 작용하는 사용자로부터 검색 쿼리를 수신하는 단계의 동작;

데이터 아이템들의 상기 콜렉션으로부터 제1 데이터 아이템들― 상기 제1 데이터 아이템들은 상기 검색 쿼리를 충족시키고, 상기 제1 데이터 아이템들은 상기 제1 데이터 아이템들로부터 추출된 제1 속성들을 집합적으로 구비함―에 대한 선택을 수신하는 단계의 동작;

제1 데이터 아이템들로부터 추출된 제1 속성 각각에 대한 속성 빈도―상기 속성 빈도는 상기 검색 엔진의 이전 사용자들이 검색 결과들을 신속하게 좁히기 위해 미리 결정된 시간 기간 동안에 상기 제1 속성들 각각을 선택한 개별적 빈도임―를 결정하는 단계의 동작;

가장 높은 개별적 속성 빈도를 갖는 상기 제1 속성들을 코어 그룹 속성―상기 코어 그룹 속성은 모든 상기 제1 속성보다 적은 속성들은 포함함―으로서 선택하는 단계의 동작;

2개 이상의 상기 제1 데이터 아이템들 각각에 대한 개별적 참조 및 상기 코어 그룹의 속성 각각에 대한 개별적 표시를 포함하는 검색 엔진 결과 페이지를 상기 클라이언트 디바이스에 출력하는 단계의 동작;

쿼리 한정을 수신하기 위한 검색 창을, 상기 코어 그룹의 하나 이상의 속성의 표시에 대한 사용자 선택에 응답하여 제공하는 단계의 동작; 및

상기 검색 쿼리와 상기 쿼리 한정을 충족시키는 제2 데이터 아이템들에 대한 선택을 수신하는 단계의 동작을 포함하는 시스템.
청구항 6에 있어서,

상기 콜렉션에 대한 웹 탐색을 실행하는 단계의 동작을 더 포함하고, 상기 콜렉션은 상기 데이터 아이템들 및 이 데이터 아이템 각각의 정보 유형을 설명하는 연관된 속성들을 저장하는 시스템.
청구항 1에 있어서, 단일 데이터 제공자로부터 데이터 아이템들과 상기 속성들의 콜렉션 및 상기 데이터 아이템들의 속성들을 수신하는 단계를 더 포함하는 방법.
청구항 1에 있어서, 상기 속성들을 추출하는 단계는

데이터 아이템의 정보 유형을 결정하는 단계;

정보 유형들을 속성들에 매핑시키는 데이터 구조에 접근하는 단계; 및

상기 정보 유형을 상기 데이터 구조에 적용하는 것에 기초하여, 상기 데이터 아이템에 관련된 상기 속성들을 결정하는 단계를 더 포함하는 방법.
청구항 1에 있어서, 상기 속성들을 추출하는 단계는 상기 데이터 아이템들을 대상으로 임의의 검색이 발생하기 전에 상기 속성들을 추출하는 단계를 더 포함하는 방법.
청구항 1에 있어서,

상기 데이터 아이템들의 제공자가 상기 데이터 아이템들에 관련된 상기 속성들을 편집하도록 하는 사용자 인터페이스를 생성하는 단계; 및

하나 이상의 상기 데이터 아이템에 관련된 속성을 변화시키는 정보를 상기 사용자 인터페이스를 통해 수신하는 단계를 더 포함하는 방법.
청구항 4에 있어서,

단일 데이터 제공자로부터 데이터 아이템들과 상기 속성들의 콜렉션 및 상기 데이터 아이템들의 속성들을 수신하는 단계의 동작을 더 포함하는 컴퓨터 판독 가능 매체.
청구항 4에 있어서, 상기 속성들을 추출하는 단계는

데이터 아이템의 정보 유형을 결정하는 단계;

정보 유형들을 속성들에 매핑시키는 데이터 구조에 접근하는 단계; 및

상기 정보 유형을 상기 데이터 구조에 적용하는 것에 기초하여, 상기 데이터 아이템에 관련된 상기 속성들을 결정하는 단계를 더 포함하는 컴퓨터 판독 가능 매체.
청구항 4에 있어서, 상기 속성들을 추출하는 단계는 상기 데이터 아이템들을 대상으로 임의의 검색이 발생하기 전에 상기 속성들을 추출하는 단계를 더 포함하는 컴퓨터 판독 가능 매체.
청구항 4에 있어서,

상기 데이터 아이템들의 제공자가 상기 데이터 아이템들에 관련된 상기 속성들을 편집하도록 하는 사용자 인터페이스를 생성하는 단계; 및

하나 이상의 상기 데이터 아이템에 관련된 속성을 변화시키는 정보를 상기 사용자 인터페이스를 통해 수신하는 단계를 더 포함하는 컴퓨터 판독 가능 매체.
청구항 6에 있어서,

단일 데이터 제공자로부터 데이터 아이템들과 상기 속성들의 콜렉션 및 상기 데이터 아이템들의 속성들을 수신하는 단계의 동작을 더 포함하는 시스템.
청구항 6에 있어서, 상기 속성들을 추출하는 단계는

데이터 아이템의 정보 유형을 결정하는 단계;

정보 유형들을 속성들에 매핑시키는 데이터 구조에 접근하는 단계; 및

상기 정보 유형을 상기 데이터 구조에 적용하는 것에 기초하여, 상기 데이터 아이템에 관련된 상기 속성들을 결정하는 단계를 더 포함하는 시스템.
청구항 6에 있어서, 상기 속성들을 추출하는 단계는 상기 데이터 아이템들을 대상으로 임의의 검색이 발생하기 전에 상기 속성들을 추출하는 단계를 더 포함하는 시스템.
청구항 6에 있어서,

상기 데이터 아이템들의 제공자가 상기 데이터 아이템들에 관련된 상기 속성들을 편집하도록 하는 사용자 인터페이스를 생성하는 단계의 동작; 및

하나 이상의 상기 데이터 아이템에 관련된 속성을 변화시키는 정보를 상기 사용자 인터페이스를 통해 수신하는 단계의 동작을 더 포함하는 시스템.
삭제