KR20090091364A - 검색 정보 처리 방법 및 처리 시스템 - Google Patents

Abstract

본 발명은 검색 정보 처리 방법 및 시스템에 관한 것이다. 제 1 양태에 따르면, 데이터 자원의 검색을 용이하게 하는 방법 및 시스템이 제공된다. 제 2 양태에 따르면, 네트워크-기반 시장에서 아이템을 거래하는 판매자 및 구매자에 의해 이용되는 데이터 자원 검색을 위한 쿼리를 생성하는 방법 및 시스템이 제공된다. 제 3 양태에 따르면, 네트워크-기반 시장에서 판매자들에 의해 목록이 작성된 목록들을 구매자가 브라우징할 수 있게 하는 방법 및 시스템이 제공된다. 제 4 양태에 따르면, 네트워크-기반 시장에서 판매자들에 의해 목록이 작성된 데이터 목록들을 식별하는데 이용되는 특성들을 취소하는 방법 및 시스템이 제공된다. 제 5 양태에 따르면, 데이터 아이템들을 유저에게 표시하는데 이용되는 유저 인터페이스와 연관된 영역의 사이즈를 결정하는 방법 및 시스템이 제공된다.

검색 정보 처리, 데이터 자원, 데이터 아이템, 유저 인터페이스, 쿼리

Description

검색 정보 처리 방법 및 처리 시스템{METHODS AND SYSTEMS TO PROCESS SEARCH INFORMATION}

관련 출원

본 출원은 참조로 여기에 포함된, 2005년 3월 30일자로 출원된 미국 가출원 제 60/666,549 호의 우선권을 주장한다.

기술 분야

본 출원은 일반적으로 데이터 통신의 기술 분야에 관한 것이고, 일 실시예로, 검색 정보 처리를 위한 방법 및 시스템에 관한 것이다.

배경

특정 정보를 검색하기 위해 정보 자원을 검색하는 유저는 난제에 직면하게 된다. 이러한 난제 중 하나는 정보 자원 검색에 이용되는 검색 메커니즘 (예를 들어, 검색 엔진) 이 유저가 관심이 있는 정보 결과를 유저에게 제공하는 데 실패할 수도 있다는 것이다. 이는 다양한 이유로 인해 발생할 수도 있다. 한 가지 이유는 예를 들어, 유저와 저자가 동일한 개념을 설명하는데 상이한 언어를 사용한다는 것일 수도 있다. 예를 들어, 네트워크 상거래 시스템의 면에서, 목 록의 저자 (예를 들어, 판매자) 는 한 쌍의 슬리퍼를 "루비색 슬리퍼" 라고 목록을 작성하고, 유저 (예를 들어, 잠재적 구매자) 는 검색하기 위한 키워드 쿼리 (query) 를 "빨간색 슬리퍼" 라고 입력할 수도 있다. 유저가 실제로 "루비색 슬리퍼" 를 의미한 것이었다면 이는 실망스러운 것이 된다. 또 다른 예로는, 판매자가 "루비색 슬리퍼" 라고 목록을 작성한 카테고리 (예를 들어, "신발류") 에서 구매자가 발견하는데 실패했기 때문에, 구매자는 "루비색 슬리퍼" 라는 목록을 발견하지 못할 수도 있다. 사람들은 그들이 뜻하는 것을 항상 말하지는 않으며, 그들이 원하는 것을 어떻게 찾는지를 항상 알지는 못한다.

또 다른 문제점으로는, 정보 자원 (예를 들어, 전자 시장) 은 유저가 획득에 관심이 없는 아이템들을 유저에게 제공함으로써 유저의 검색에 대해 반응하는 것이다. 예를 들어, 유저 (예를 들어, 잠재적 구매자) 가 아이템을 검색하기 위해 키워드 "AK" 를 포함하고, 전자 시장은 앤 클라인 어패럴 (예를 드리어, AK-스웨터) 및 러시아제 소총 (예를 들어, AK47) 을 리턴할 수도 있다. 유저는 아마도 이 양 타입의 아이템에 관심이 없을 것이고, 그들의 검색에 대해 좀 더 정확한 응답을 원할 것이다.

저자 (예를 들어, 판매자) 가 정확하게 쓰고 서류를 작성 (예를 들어, 목록이 포함하는 아이템을 식별) 하지 않는다면 상기한 문제점들은 더욱 악화될 수도 있다. 예를 들어, 판매자들은 전자 시장에 DVD 플레이어를 목록에 올릴 수도 있다. 특정 DVD 플레이어가 다른 DVD 플레이어와 유사한 (또는 상이한) 것은 판매자에 의해 명확하게 식별되지 못할 수도 있다. 전자 시장은 구매자의 쿼리 (예를 들어, 키워드 쿼리 또는 브라우징 (browsing) 선택) 에 기초하여 구매자에게 어떤 DVD 를 제공할 것인지를 결정해야만 하기 때문에, 이는 대답해야 할 중요한 질문이다. 반면, 일부 전자 시장은 제품을 고유하게 식별하는 제품 넘버 (예를 들어, 통일 상품 넘버 (Universal Product Number; UPN)) 를 판매자에게 요구함으로써 그들이 판매하고 있는 아이템을 정확하게 식별할 것을 요구한다. 이들 시장은 그들의 재고 목록에 관해 정확한 지식을 구비하고 있으며, 구매자의 쿼리의 의미를 이해하는 데에만 관심을 두면 된다.

상술한 정보 자원 검색에 이용되는 검색 메커니즘 (예를 들어, 검색 엔진) 이 유저가 관심이 있는 정보 결과를 유저에게 제공하는 데 실패하는 문제, 정보 자원 (예를 들어, 전자 시장) 이 유저가 획득에 관심이 없는 아이템들을 유저에게 제공함으로써 유저의 검색에 대해 반응하는 문제 등을 해결하는 방법 및/또는 장치가 필요하다.

제 1 양태에 따르면, 네트워크-기반 시장에서 아이템들을 거래하는 판매자들 및 구매자들에 의해 이용되는 데이터 자원 검색을 용이하게 하는 시스템이 제공되고, 이 시스템은, 판매자로부터 아이템과 연관된 정보를 수신하는 수신 모듈; 표현이 참이라고 평가하면 정보를 보충하기 위해 이용되는 표현 및 보충 정보를 포함하는 규칙을 이용하여 상기 정보를 평가하기 위한 규칙 적용 모듈; 및 정보 및 보충 정보를 저장하기 위한 처리 모듈을 포함하고, 평가, 보충, 및 저장은 실시간으로 정보 및 보충 정보의 검색을 용이하게 하기 위해 실시간으로 수행되고, 정보를 평가하는 것은, 제목, 설명, 목록 카테고리, 아이템 명세, 가격, 판매 형식, 판매 기간, 옥션 기간, 지불 방법, 운송 정보, 아이템 위치, 및 구매자 요구들을 포함하는 그룹에서 하나 이상을 평가하는 것을 포함하고, 판매 형식은 고정-가격 형식 및 옥션 형식을 포함하는 형식들의 그룹 중 임의의 하나를 포함하고, 아이템 명세는 아이템의 상태를 설명하고, 수신 모듈은 USBN 넘버, 통일 상품 넘버, 통일 상품 코드 및 고유 명사를 포함하는 그룹에서 하나 이상을 식별하기 위한 정보를 검색하고, 수신 모듈은 카탈로그 정보를 아이템 정보에 부가하고, 아이템 정보에 등록할 하나 이상의 도메인을 결정하기 위한 분류 엔진을 추가로 포함하고, 도메인은 제품 타입 및 서비스 타입을 포함하는 그룹에서 임의의 하나를 포함하고, 규칙은 분류 규칙들 및 추론 규칙들을 포함하는 규칙들의 그룹으로부터 선택되며, 분류 규칙은 구매자에 의한 검색을 용이하게 하기 위해 개념을 정보에 연관시키는데 이용되고, 추론 규칙은 구매자에 의한 검색을 용이하게 하기 위해 정보에 연관된 개념을 추론하는데 이용되고, 보충 정보는 개념 및 값을 포함하는 개념-값 쌍을 포함하고, 개념은 값을 포함하는 복수의 값들과 연관되고, 처리 모듈은 추론 정보를 추론하기 위해 정보에 연관된 분류 정보를 평가한다.

제 2 양태에 따르면, 네트워크-기반 시장에서 아이템들을 거래하는 판매자 및 구매자에 의해 이용되는 데이터 자원 검색을 위한 쿼리를 생성하는 시스템이 제공되고, 이 시스템은, 구매자로부터 하나 이상의 키워드를 포함하는 키워드 쿼리를 수신하기 위한 계산 모듈; 및 표현 및 분류 정보를 포함하는 하나 이상의 규칙을 이용하여 하나 이상의 키워드를 평가하기 위한 쿼리 생성 모듈을 포함하고, 쿼리 생성 모듈은 표현이 참이라고 평가하면 쿼리에 분류 정보를 포함하고, 분류 정보는 데이터 자원에 저장된 보충 정보를 검색하기 위해 이용되며, 보충 정보는 판매자에 의해 입력되는 아이템 정보로부터 생성되며, 정보는 제목, 설명, 목록 카테고리, 아이템 명세, 가격, 판매 형식, 판매 기간, 옥션 기간, 지불 방법, 운송 정보, 아이템 위치, 및 구매자 요구들을 포함하는 그룹 중 하나 이상을 포함하고, 아이템 명세는 네트워크-기반 시장에서 거래되는 아이템의 상태를 설명하며, 분류 정보는 키워드에 매칭되는 값을 포함하고, 쿼리 생성 모듈은 표현을 포함하고 도메인에 연관되는 규칙을 이용하여 하나 이상의 키워드를 평가함으로써 도메인을 판정한다.

제 3 양태에 따르면, 네트워크-기반 시장에서 판매자들에 의해 목록이 작성되고, 데이터 자원에 저장된 아이템들의 목록들을 구매자가 브라우징할 수 있게 하는 시스템이 제공되고, 이 시스템은, 개념 및 그 개념과 연관되는 2 이상의 값들을 표시하는 유저 인터페이스를 생성하기 위한 검색 애플리케이션; 및 2 이상의 값들에 대응하는 구매자로부터의 2 이상의 선택들을 수신하기 위한 결정 모듈을 포함하고, 2 개의 선택들은 데이터 자원에 저장되고 판매자에 의해 입력된 정보의 평가에 기초하여 2 이상의 값들과 연관되는 하나 이상의 목록을 식별하기 위해 이용되며, 정보를 분류하고 부가 정보를 추론하기 위해 이용되는 규칙들의 그룹으로부터의 2 이상의 규칙들에 기초하여, 정보가 2 이상의 값들로 특성화되고, 정보는 제목, 설명, 목록 카테고리, 아이템 명세를 포함하는 그룹에서 하나 이상을 포함하고, 판매 형식은 고정-가격 형식 및 옥션 형식을 포함하는 형식들의 그룹 중 임의의 하나를 포함하고, 아이템 명세는 목록에 의해 설명되는 아이템의 상태를 설명하고, USBN 넘버, 통일 상품 넘버, 통일 상품 코드 및 고유 명사를 포함하는 그룹에서 하나 이상을 식별하기 위해 정보를 검색하고, 아이템 정보에 카탈로그 정보를 부가하는 수신 모듈을 추가로 포함하고, 하나 이상의 목록은 복수의 값들과 각각 연관되는 복수의 개념들과 연관되며, 상기 개념은 구매자로부터 수신되는 쿼리에 기초하여 결정되고, 하나 이상의 목록을 식별하기 위해 2 이상의 선택들이 쿼리와 결합되며, 유저 인터페이스는 개념과 연관되는 부가적인 값들을 포함하는 제 2 유저 인터페이스를 구매자가 요청할 수 있도록 한다.

제 4 양태에 따르면, 네트워크-기반 시장에서 판매자들에 의해 작성된 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템이 제공되고, 이 시스템은, 목록들을 식별하는데 이용되는 복수의 특성들을 유저에 전달하기 위한 검색 애플리케이션; 가장 최근에 선택된 특성 이외의 특성을 취소하는 유저로부터의 선택을 수신하고, 그 선택에 기초하여, 가장 최근에 선택된 특성을 포함하는 나머지 복수의 특성들을 식별하기 위한 결정 모듈을 포함하고, 결정 모듈은, 판매자에 의해 입력된 정보의 평가에 기초하여 나머지 특성들을 보이고자 결정된 하나 이상의 목록을 식별하기 위해 복수의 나머지 특성들을 이용하고, 검색 애플리케이션은, 복수의 나머지 특성들 및 하나 이상의 목록을 유저에게 전달하고, 복수의 특성들은 개념-값 쌍을 포함하는 특성을 포함하고, 나머지 특성들은 정보를 분류하는데 이용되는 규칙들 및 부가 정보를 추론하는 규칙들에 기초한 정보와 연관되며, 정보는 제목, 설명, 목록 카테고리, 아이템 명세, 가격, 판매 형식, 판매 기간, 옥션 기간, 지불 방법, 운송 정보, 아이템 위치, 및 구매자 요구들을 포함하는 그룹 중 하나 이상을 포함하고, 판매 형식은 고정-가격 형식 및 옥션 형식을 포함하는 형식들의 그룹 중 임의의 하나를 포함하고, 복수의 특성들은 개념-값 쌍을 포함하는 특성을 포함한다.

제 5 양태에 따르면, 데이터 아이템들을 표시하는데 이용되는 유저 인터페이스 상의 제 1 영역의 사이즈를 결정하는 시스템이 제공되고, 이 시스템은, 서로 사 이즈 면에서 상보적인, 데이터 아이템들을 표시하는데 이용되는 제 1 영역 및 다른 정보를 표시하는데 이용되는 제 2 영역을 포함하는 유저 인터페이스에 대한 요청을 수신하기 위한 검색 애플리케이션; 및 제 1 영역에 표시될 데이터 아이템들의 수를 계산하는 것에 응답하여 제 1 영역의 사이즈를 결정하기 위한 결정 모듈을 포함하고, 검색 애플리케이션은 제 2 영역 내에, 결정된 사이즈의 제 1 영역을 포함하도록 유저 인터페이스를 생성하고, 결정 모듈은, 제 1 영역에 표시될 것으로 계산된 데이터 아이템들의 수를 소정의 임계값과 비교하고, 소정의 임계값은 구성가능한 값이고, 표시될 것으로 계산된 데이터 아이템들의 수가 소정의 임계값보다 더 작으면, 제 1 영역의 표시가능한 면적은 증가하고, 제 2 영역의 표시가능한 면적은 감소하고, 데이터 아이템들의 수가 소정의 임계값 이상이면, 제 1 영역의 사이즈는 감소하고, 제 2 영역의 사이즈는 증가하고, 제 2 영역은, 데이터 아이템들을 식별하기 위해 유저에 의해 이용되는 브라우징 옵션들을 제공하기 위해 이용되고, 유저에게 제공되는 브라우징 옵션들은 유저에 의해 입력되는 키워드 쿼리에 기초하여 선택되고, 제 2 영역은, 데이터 아이템들의 수에 기초하여 감소하고, 브라우징 옵션을 표시하기 위해 유저에 의해 선택가능한 버튼을 포함하며, 유저는 구매자이고, 데이터 아이템들은 네트워크-기반 시장 상의 목록들이다.

상술한 정보 자원 검색에 이용되는 검색 메커니즘 (예를 들어, 검색 엔진) 이 유저가 관심이 있는 정보 결과를 유저에게 제공하는 데 실패하는 문제, 정보 자원 (예를 들어, 전자 시장) 이 유저가 획득에 관심이 없는 아이템들을 유저에게 제 공함으로써 유저의 검색에 대해 반응하는 문제 등을 해결할 수 있다.

정보 검색을 처리하기 위한 방법 및 시스템이 설명된다. 이하의 설명에서, 예시적인 목적으로, 많은 구체적인 상세한 내용들이 본 발명의 완전한 이해를 제공하기 위해 전개된다. 하지만, 당업자에게 있어 본 발명이 이들 구체적인 상세한 내용들 없이도 실시될 수도 있다는 것은 자명하다.

제 1 양태에 따라, 데이터 자원의 검색을 용이하게 하기 위한 방법 및 시스템이 제공된다. 시스템은 아이템과 연관된, 판매자로부터의 정보를 수신하고, 그 수신 정보를 표현 (예를 들어, 불리언 (Boolean)) 및 보충 정보를 포함하는 규칙에 따라 실시간으로 평가한다. 그 표현이 참이라고 평가되면, 시스템은 그 보충 정보를 데이터 자원의 수신 정보와 실시간으로 연관시키고 저장한다. 보충 정보는 분류 정보 및 추론 정보를 포함할 수도 있다. 분류 정보는 정보 검색에 나중에 이용될 수도 있는 개념에 따른 정보를 구조화하는데 이용될 수도 있다. 추론 정보는 수신 정보로부터 도출될 수도 있고 (예를 들어, 루비색은 빨간색의 일유형이기 때문에 빨간 색은 루비색으로부터 도출될 수도 있다), 또한 정보 검색에 나중에 이용될 수도 있다.

제 2 양태에 따라, 네트워크-기반 시장에서 아이템을 거래하는 판매자와 구매자에 의해 이용되는 데이터 자원을 검색하기 위한 쿼리를 생성하는 방법 및 시스템이 제공된다. 시스템은 구매자로부터 키워드 쿼리를 수신하고, 표현 (예를 들어, 불리언) 및 분류 정보를 포함하는 규칙에 따라 키워드 쿼리의 키워드를 평가 한다. 그 표현이 참이라고 평가되면, 시스템은 키워드 쿼리에 대응하고 분류 정보를 포함하는 개념 쿼리를 생성한다. 이 개념 쿼리는 그 후에, 판매자에 의해 입력된 정보로부터 생성된 (예를 들어, 전술한 제 1 양태에 따른) 분류 정보를 포함하는 데이터 자원의 정보 (예를 들어, 쿼리) 를 검색하는데 이용될 수도 있다.

제 3 양태에 따라, 네트워크-기반 시장에서 판매자에 의해 목록이 작성된 목록들을 구매자가 브라우징할 수 있도록 하는 방법 및 시스템이 제공된다. 시스템은 개념 및 그 개념과 연관된 다수의 값들을 표시하는 유저 인터페이스를 생성한다. 시스템은, 네트워크-기반 시장 상의 목록들을 식별하는데 이용될 수도 있는 값들에 대응하는, 구매자로부터의 2 이상의 선택을 수신할 수도 있다. 예를 들어, 신발에 대한 유저 인터페이스는 브랜드 (예를 들어, 개념) 및 Nike, Reebok, Keds 등의 브랜드 명칭 (예를 들어, 값들) 을 포함할 수도 있다. 구매자는 2 이상의 브랜드 명칭을 선택할 수도 있고, 이는 시스템에 의해 수신되고, 판매자에 의해 입력된 정보에 기초하여 그 선택된 값들 (예를 들어, Nike 및 Reebok) 을 나타내는 신발을 식별하고 표시하기 위해 시스템에 의해 이용된다.

제 4 양태에 따라, 네트워크 기반 시장 상에서 판매자에 의해 목록이 작성된 데이터 목록들을 식별하는데 사용되는 특성을 취소하는 방법 및 시스템이 제공된다. 시스템은, 데이터 아이템들을 식별하기 위해 유저에 의해 선택될 수도 있는 목록들을 식별하는데 이용되는 한 셋트의 특성들을 전달한다. 그 다음, 유저는 가장 최근에 선택된 특성 이외의 특성을 취소할 수도 있다. 이에 응답하 여 시스템은, 판매자에 의해 입력된 정보의 평가에 기초하여 나머지 특성들을 나타내기 위해 결정된 데이터 아이템들을 식별하기 위해 나머지 특성들을 이용할 수도 있다.

제 5 양태에 따라, 데이터 아이템들을 유저에게 표시하는데 이용되는 유저 인터페이스와 연관된 영역의 사이즈를 결정하는 방법 및 시스템이 제공된다. 시스템은 사이즈 면에서 상보적인 2 개의 영역을 포함하는 유저 인터페이스에 대한 요구를 수신한다. 시스템은, 제 1 영역은 데이터 아이템들을 표시하기 위해 사용하고, 제 2 영역은 데이터 소스의 데이터 아이템들을 식별하기 위해 유저에 의해 선택될 수도 있는 브라우징 옵션들을 표시하기 위해 사용한다. 시스템은, 제 1 영역에 표시될 데이터 아이템의 수를 계산하여 데이터 아이템들을 표시하기 위한 영역과 연관된 사이즈를 자동으로 결정한다. 제 1 영역에 표시될 데이터 아이템의 수가 소정 임계값을 초과하면, 시스템은 데이터 아이템들을 표시할 영역을 감소시키고, 브라우징 옵션들과 연관된 영역을 증가시킨다. 따라서, 데이터 아이템들의 높은 카운트 수는, 데이터 소스의 데이터 아이템들을 식별하기 위해 유저에 의해 선택될 수도 있는 브라우징 옵션들을 강조하는 유저 인터페이스의 생성을 야기할 수도 있다.

제 6 양태에 따라, 클라이언트 컴퓨터에서 브라우저 백 (back) 버튼의 선택을 처리하기 위한 방법 및 시스템이 제공된다. 시스템은 클라이언트 컴퓨터에서 브라우저에 의해 처리된 브라우저 백 버튼 선택을 수신하고, 표시가능한 유저 인터페이스 엘리먼트들을 포함하지 않는 유저 인터페이스를 복구한다. 복구된 유저 인터페이스의 아이덴터티 (identity) 는, 백 버튼의 선택에 응답하여 표시될 것이라 유저가 기대하는 유저 인터페이스를 식별하기 위해 요청된 유저 인터페이스의 아이덴터티를 이용하는 클라이언트 애플리케이션 프로그램 (예를 들어, 스크립트, 애플릿 등) 에 의해 모니터링된다.

개요

도 1 은 데이터 자원을 검색하기 위한, 일 실시형태에 따른, 컴퓨터-기반 시스템 (11) 을 나타내는 블록도이다. 다음의 것들에 대한 예시적인 내용들을 제공하기 위해 시스템 (11) 이 설명된다. 동작 13 에서, 저자 또는 발행인 (예를 들어, 판매자) 는 정보 아이템들을 포함하는 정보 (예를 들어, 아이템 설명) 를 클라이언트 컴퓨터로 입력한다. 클라이언트 컴퓨터는 그 정보를 시스템 (11) (예를 들어, 컴퓨터-기반 시스템) 에 전달하고, 여기에서 정보는 데이터베이스에 저장된다. 아이템 설명 (item description) (또는 목록) 은 제목, 설명, 하나 이상의 목록 카테고리 등을 포함할 수도 있다.

동작 15 에서, 분류 엔진은 수신 정보를 위한 도메인을 결정하고 (예를 들어, 아이템 설명이 신발, 장난감, 책 등에 관련되었는지를 결정), 그 수신 정보에 분류 및 추론 태그들을 부가하고, 분류 태그들 및 추론 태그들을 수신 정보와 함께 데이터 자원 (예를 들어, 메모리, 데이터베이스, 저장 장치 등) 에 저장한다. 분류 엔진은 도메인 특정 쿼리들을 아이템에 적용하여 아이템에 대한 도메인을 결정한다. 분류 엔진은, 분류 규칙들의 수신 정보에의 적용에 응답하여 분류 태그들을 수신 정보에 부가할 수도 있다. 예를 들어, 분류 엔진은 "루비색" (예 를 들어, 아이템 정보) 를 판독하고, "컬러 = 루비색" (예를 들어, 분류 태그) 를 생성하여 응답할 수도 있다. 따라서, 아이템 정보 "루비색" 는 "컬러" 라는 개념 아래에 구조화된다. 또한, 분류 엔진은 추론 규칙들의 아이템 정보 및 분류 태그들에의 적용에 응답하여 추론 태그들을 부가할 수도 있다. 예를 들어, 분류 엔진은 "컬러 = 루비색" (예를 들어, 분류 태그) 를 판독하고, "컬러 = 빨간색" (예를 들어, 추론 태그) 를 생성하여 응답할 수도 있다. 따라서, 추론 태그 "컬러 = 빨간색" 은 "루비색" 이 "빨간색" 의 일 유형이라고 추론함으로써 정보를 아이템 정보에 부가한다.

동작 17 에서, 유저는 키워드 쿼리를 입력하고, 이는 클라이언트 컴퓨터에 의해 수신되며, 클라이언트 컴퓨터는 그 키워드 쿼리를 컴퓨터-기반 시스템 (11) 에 전달한다.

동작 19 에서, 키워드 쿼리가 수신되어, 도메인 및 개념 쿼리를 생성하기 위해 검색 애플리케이션에 의해 이용된다. 예를 들어, 키워드 쿼리 "Nike 검정색 사이즈 8" 이 이용되어 도메인 "신발" 및 개념 쿼리 "브랜드 = Nike", "컬러 = 검정색", "사이즈 = 사이즈 8" 을 생성할 수도 있다.

동작 21 에서, 도메인 및 개념 쿼리가 분류 엔진에 의해 수신되어, 구매자에게 제공하기 위한 정보 (예를 들어, 아이템 목록들) 를 발견하는데 이용된다. 본 실시예에 계속하여, 분류 엔진은, 개념 쿼리 "브랜드 = Nike" 또는 "컬러 = 검정색" 또는 "사이즈 = 사이즈 8" 에 매칭되는 분류 태그들 또는 추론 태그들을 포함하는 "신발" 도메인의 아이템 목록들을 검색할 수도 있다.

동작 23 에서, 검색 애플리케이션들은 유저가 그들의 검색을 더 세분화할 수 있도록 브라우징 셋트들을 결정할 수도 있다. 브라우징 셋트는 브라우징 개념 (예를 들어, 가격 범위) 및 다수의 브라우징 값들 (예를 드리어, $1.00 내지 $5.00, $5.00 내지 $10.00, $10.00 내지 $15.00) 을 포함할 수도 있다. 유저는 브라우징 특성, 브라우징 개념-브라우징 값 쌍 (예를 들어, 가격 범위-$1.00-$5.00) 를 효과적으로 특정하는 브라우징 값을 선택할 수도 있다. 따라서, 검색 애플리케이션들은 유저에 의해 선택될 수도 있는 다수의 브라우징 특성들을 결정할 수도 있다.

동작 25 에서, 컴퓨터-기반 시스템 (11) 은 개념 쿼리, 도메인, 다수의 브라우징 특성들, 및 아이템들의 목록을 유저에게 제공한다.

정의

본 명세서에서 "값" 이라는 말은 숫자 정보 또는 텍스트 정보 또는 텍스트 정보를 의미하는 숫자 정보 (예를 들어, 1 = 빨간색, 2 = 파란색 등), 또는 숫자 정보를 의미하는 텍스트 정보 또는 이들의 임의의 조합을 의미한다.

본 명세서에서 "실시간" 이라는 문구는 지연이 없거나 아주 작은 지연을 갖는 것을 의미한다.

플랫폼 아키텍쳐

도 2 는 클라이언트-서버 아키텍쳐를 갖는, 일 실시형태에 따른, 시스템 (10) 을 나타내는 네트워크도이다. 컴퓨터-기반 시스템 플랫폼 (12) (예를 들어, 컴퓨터-기반 시스템) 은 서버측 기능을 네트워크 (14) (예를 들어, 인터넷) 를 통해 하나 이상의 클라이언트에게 제공한다. 도 2 는 예를 들어, 웹 클라이언트 (16) (예를 들어, Washington State Redmond 의 Microsoft Corporation 에 의해 개발된 인터넷 익스플로러 브라우저와 같은 브라우저), 및 각각의 클라이언트 머신들 (20 및 22) 상에서 실행하는 프로그램적 클라이언트 (18) 를 나타낸다.

구체적으로 컴퓨터-기반 시스템 (12) 으로 돌아가서, 애플리케이션 프로그램 인터페이스 (API) 서버 (24) 및 웹 서버 (26) 는 하나 이상의 애플리케이션 서버 (28) 에 연결되어, 프로그램적 인터페이스와 웹 인터페이스를 각각 제공한다. 애플리케이션 서버 (28) 는 하나 이상의 애플리케이션 (30) 을 호스팅한다. 한편, 애플리케이션 서버 (28) 는 하나 이상의 데이터베이스 (36) 에의 액세스를 용이하게 하는 하나 이상의 데이터베이스 서버 (34) 에 연결되는 것으로 나타내어져 있다. 컴퓨터-기반 시스템 (12) 은 관리자 (33) 를 포함하는 것으로 나타나 있고, 관리자 (33) 는 메타데이터 (예를 들어, 검색 메타데이터) 를 입력할 수도 있고, 이는 데이터베이스 서버 (34) 를 통해 데이터베이스 (36) 에 저장될 수도 있다.

애플리케이션 (30) 은 많은 상거래 기능들 및 서비스를 컴퓨터-기반 시스템 (12) 에 접속하는 유저들에게 제공한다.

또한, 도 2 에 나타낸 시스템 (10) 은 클라이언트-서버 아키텍쳐를 채용하고 있지만, 이 응용 코스에서 설명된 양태들은 이러한 아키텍쳐에 한정되지 않고, 분산, 또는 피어-투-피어 (peer-to-peer) 아키텍쳐 시스템의 응용도 똑같이 잘 발견할 것이다. 다양한 애플리케이션들 (30 및 32) 은 독립적 소프트웨어 프로그램 들로서 또한 구현될 수도 있고, 이는 반드시 네트워킹 기능을 가질 필요는 없다.

웹 클라이언트 (16) 는 웹 서버 (26) 에 의해 지원되는 웹 인터페이스를 통해 다양한 애플리케이션들 (30) 에 액세스한다는 것을 알 수 있을 것이다. 유사하게, 프로그램적 클라이언트 (18) 는, API 서버 (24) 에 의해 제공되는 프로그램적 인터페이스를 통해 애플리케이션들 (30) 에 의해 제공되는 다양한 서비스 및 기능들을 액세스한다. 프로그램적 클라이언트 (18) 는 예를 들어, 판매자들이 오프-라인 방식으로 컴퓨터-기반 시스템 (12) 상에서 목록들을 쓰고 운영하는 것을 가능하게 하고, 프로그램적 클라이언트 (18) 와 컴퓨터-기반 시스템 (12) 사이에서 배치-모드 통신을 수행할 수 있도록 하는 판매자 애플리케이션 (예를 들어, California San Jose 의 eBay Inc. 에 의해 개발된 TurboLister 애플리케이션) 일 수도 있다.

도 2 는 또한, API 서버 (24) 에 의해 제공되는 프로그램적 인터페이스를 통해 컴퓨터-기반 시스템 (12) 에 액세스하는 프로그램적 액세스를 갖는, 제 3 파티 (party) 서버 머신 (40) 상에서 실행하는 제 3 파티 애플리케이션 (38) 을 나타낸다. 예를 들어, 제 3 파티 애플리케이션 (38) 은 컴퓨터-기반 시스템 (12) 으로부터 복구된 정보를 이용하여 제 3 파티에 의해 호스팅되는 웹사이트 상에서 하나 이상의 피쳐들 (features) 또는 기능들을 지원한다. 제 3 파티 웹사이트는, 예를 들어, 컴퓨터-기반 시스템 (12) 의 상관 애플리케이션에 의해 지원되는 하나 이상의 판촉, 상거래 또는 지불 기능들을 제공할 수도 있다.

애플리케이션

도 3 은, 일 실시예에서, 컴퓨터-기반 시스템 (12) 의 일부로서 제공되는 다수의 애플리케이션들 (30) 을 나타내는 블록도이다. 컴퓨터-기반 시스템이 네트워크 기반 시장을 지원할 수도 있는 일 실시예에서, 컴퓨터-기반 시스템 (12) 은 많은 목록 및 가격 설정 메커니즘을 제공할 수도 있고, 이에 의해 판매자는 판매용 상품 또는 서비스의 목록을 작성할 수도 있고, 구매자는 이러한 상품 또는 서비스에 대해 관심을 표현하거나 구매할 의향을 나타낼 수 있고, 이 상품 또는 서비스에 관한 거래에 대해 가격이 설정될 수 있다. 이러한 목적으로, 애플리케이션들 (30) 은, 옥션-형식 목록 및 가격 설정 메커니즘을 지원하는 하나 이상의 옥션 애플리케이션들 (44) (예를 들어, 영어, 네델란드어, 비크리 (Vickrey), 중국어, 더블, 리버스 (reverse) 옥션 등) 을 포함하는 것으로 나타내어져 있다. 다양한 옥션 애플리케이션들 (44) 은 또한, 경매자가 자동 프록시 비딩 (proxy bidding) 을 유발할 수도 있는 프록시-비딩 피쳐 및 목록과 함께 예비 가격을 판매자가 특정할 수도 있는 예비 가격 피쳐와 같은, 이러한 옥션-형식 목록들을 지원하는 많은 피쳐들을 제공할 수도 있다.

많은 고정 가격 애플리케이션들 (46) 은 고정 가격 목록 형식들 (예를 들어, 전통적 분류의 광고 타입의 목록 또는 카탈로그 목록) 및 매점 (buyout) 타입 목록들을 지원한다. 구체적으로, (예를 들어, California San Jose 에 의해 개발된 BIN (Buy-It-Now) 기술을 포함하는) 매점 타입 목록들이 옥션-형식 목록과 함께 제공될 수도 있고, 이는 구매자가 옥션의 시작 가격보다는 통상적으로 더 높은 고정 가격으로 옥션을 통해 판매용으로 제공되는 상품 또는 서비스를 구매하도록 허용한 다.

상점 애플리케이션들 (48) 은 판매자들이 "가상의" 상점 내에 그들의 목록들을 그룹화하도록 허용하고, 이 가상 상점은 판매자들을 위해, 그리고 판매자들에 의해, 브랜드화되거나 또는 특성화된다. 이러한 가상 상점은 또한 상관 판매자에 대해 특정되고 특성화되는 판촉, 인센티브 및 피쳐들을 제공할 수도 있다.

평가 애플리케이션 (50) 은 컴퓨터-기반 시스템 (12) 을 이용하여 거래하는 파티들이 평가를 확립하고, 주장하고, 유지하도록 허용하고, 이 평가는 잠재적인 거래 파트너에 대해 이용가능하게 되고, 발행될 수도 있다. 예를 들어, 컴퓨터-기반 시스템 (12) 이 개인-대-개인 거래를 지원하는 곳에서, 유저들은 잠재적인 거래 파트너의 믿음과 신용이 사정될 수도 있는 내역 또는 다른 참조 정보를 갖지 못할 수도 있다. 평가 애플리케이션 (50) 은 유저가, 예를 들어 다른 거래 파트너들에 의해 제공되는 피드백을 통해, 컴퓨터-기반 시스템 (12) 내에서 시간에 걸쳐 평가를 확립할 수 있도록 한다. 그러면, 다른 잠재적인 거래 파트너들은 신용과 믿음을 사정할 목적으로 이러한 평가를 참조할 수도 있다.

개인화 애플리케이션 (52) 은 컴퓨터-기반 시스템 (12) 의 유저들이 그들의 컴퓨터-기반 시스템 (12) 과의 상호작용의 다양한 양태들을 개인화할 수 있도록 한다. 예를 들어, 유저는 적절한 개인화 애플리케이션 (52) 을 활용하여, 유저가 파티인 (또는 파티이었던) 거래에 관한 정보가 일람될 수도 있는 개인화된 참조 페이지를 형성할 수도 있다. 또한, 개인화 애플리케이션 (52) 은 유저가 컴퓨터-기반 시스템 (12) 및 다른 파티들과의 그들의 상호작용의 목록들과 다른 양태들을 개인화할 수 있도록 할 수도 있다.

일 실시형태에서, 컴퓨터-기반 시스템 (12) 은 예를 들어 특정 지리적 영역들에 커스터마이즈된 (customized) 많은 상거래 시스템을 지원할 수도 있다. 컴퓨터-기반 시스템 (12) 의 일 버전은 영국에 대해 커스터마이즈될 수도 있고, 한편, 컴퓨터-기반 시스템 (12) 의 다른 버전은 미국에 대해 커스터마이즈될 수도 있다. 이들 버전들의 각각은 독립적인 상거래 시스템으로서 동작할 수도 있고, 공통 기초 상거래 시스템의 커스터마이즈된 (또는 국제화된) 제공일 수도 있다.

컴퓨터-기반 시스템 (12) 에 의해 지원되는 서비스 (예를 들어, 네트워크-기반 시장) 의 네비게이션은 하나 이상의 검색 애플리케이션 (57) 에 의해 촉진될 수도 있다. 예를 들어, 검색 애플리케이션 (57) 은 컴퓨터-기반 시스템 (12) 을 통해 발행되는 정보 (예를 들어, 아이템 목록들) 의 분류를 가능하게 할 수도 있고, 키워드 쿼리들, 개념 쿼리들, 및 다중 경로 브라우징으로 아이템들의 이어지는 검색 또한 가능하게 할 수도 있다.

가능한 한 시각적으로 알리고 관심을 끌기 위해 컴퓨터-기반 시스템 (12) 을 통해 이용가능한 정보를 만들기 위해, 애플리케이션들 (30) 은 하나 이상의 이미징 애플리케이션들 (58) 을 포함할 수도 있고, 이를 이용하여 유저들은 목록들 내에 포함시키기 위해 이미지들을 업로드할 수도 있다. 이미징 애플리케이션 (58) 은 또한 일람된 정보 내에 이미지들을 통합하기 위해 동작하다. 이미징 애플리케이션 (58) 은 또한, 잠재적인 구매자들에게 제공되는 이미지 갤러리와 같은 하나 이상의 판촉 피쳐들을 지원할 수도 있다. 예를 들어, 판매자들은 판촉 아이템 정보를 위해 이미지를 이미지 갤러리 내에 포함시키기 위해 추가적인 요금을 지불할 수도 있다.

목록 형성 애플리케이션들 (60) 의 예시적인 형태에서, 저작/발행 애플리케이션들은, 저자/발행자 판매자들이 정보 (예를 들어, 컴퓨터-기반 시스템 (12) 을 통해 그들이 거래하고자 하는 상품 및 서비스를 포함하는 목록들) 를 편하게 저작할 수 있도록 하고, 애플리케이션 관리 애플리케이션 (예를 들어, 목록 관리 애플리케이션 (62)) 은 저자/발행자들이 이러한 발행된 정보를 관리할 수 있도록 한다. 예를 들어, 특정 판매자가 많은 수의 목록들을 저작 및/또는 발행한 경우, 이러한 목록들의 관리는 어려울 수도 있다. 목록 관리 애플리케이션 (62) 은 셀러가 이러한 목록들을 관리하는 것을 보조하기 위해 많은 피쳐들 (예를 들어, 자동-목록재작성, 재고 레벨 모니터 등) 을 제공한다. 하나 이상의 목록 작성 후 관리 애플리케이션 (64) 은 또한 판매자들의 목록 작성 후 통상적으로 발생하는 많은 활동들을 보조한다. 예를 들어, 하나 이상의 옥션 애플리케이션들 (44) 에 의해 용이하게 되는 옥션의 완료 시에, 구매자는 특정 판매자에 관한 피드백을 남기기를 원할 수도 있다. 이를 위해, 목록 작성 후 관리 애플리케이션 (64) 은, 구매자가 판매자에 관한 피드백을 평가 애플리케이션 (50) 에 편하게 제공할 수 있도록, 하나 이상의 평가 애플리케이션들 (50) 에 대해 인터페이스를 제공할 수도 있다. 피드백은 긍정적인 코멘트, 중립적인 코멘트, 또는 부정적인 코멘트로서 등록되는 리뷰의 형태를 취할 수도 있다. 또한, 포인트가 각각의 형태의 코멘트와 연관될 수도 있고 (예를 들어, 각각의 긍정적인 코멘트에 대해 +1 포인트, 중 립적인 코멘트에 대해 0 포인트, 부정적인 코멘트에 대해 -1 포인트), 이들을 합산하여 판매자에 대한 등급을 생성할 수도 있다.

분쟁 해결 애플리케이션 (66) 은 거래 파티들 사이에서 발생하는 분쟁들을 해결이 해결될 수도 있는 메커니즘을 제공한다. 예를 들어, 분쟁 해결 애플리케이션 (66) 은 파티들이 분쟁 해결을 시도하는 많은 단계들로 안내되는 안내 절차들을 제공할 수도 있다. 안내된 절차들을 통해 분쟁이 해결될 수 없는 경우, 분쟁은 제 3 파티 조정자 또는 중재자에게로 보내질 수도 있다.

많은 주변 행동 애플리케이션들 (68) 은 컴퓨터-기반 시스템 (12) 내에서 사기의 발생을 감소시키기 위한 다양한 사기 검출 및 방지 메커니즘들 및 높은 가치의 유저들을 식별하고 분류하는 고객 구분 메커니즘들을 구현한다.

메세징 애플리케이션들 (70) 은 예를 들어 컴퓨터-기반 시스템 (12) 의 목록들의 상태에 관하여 유저들에게 조언하는 (예를 들어, 옥션 절차 동안 입찰자들에게 "고가 책정" 통지를 제공하거나, 유저들에게 판촉 정보 및 판매 정보를 제공하는) 메세지들과 같은 메세지들을 컴퓨터-기반 시스템 (12) 의 유저들에게 생성하고 전달하는 책임을 진다.

판매 애플리케이션들 (72) 은 판매자들이 컴퓨터-기반 시스템 (12) 을 통해 판매를 증가시킬 수 있도록 하는, 판매자들에게 이용가능한 다양한 판매 기능들을 지원한다. 판매 애플리케이션들 (72) 은 또한, 판매자들이 원하는 다양한 판매 피쳐들을 동작시키고, 판매자들에 의해 채용된 판매 전략의 성공을 모니터링하고 추적할 수도 있다.

컴퓨터-기반 시스템 (12) 그 자체, 또는 그 컴퓨터-기반 시스템 (12) 을 통해 거래하는 하나 이상의 파티들은 하나 이상의 로열티/판촉 애플리케이션들 (74) 에 의해 지원되는 로열티 프로그램들을 동작시킬 수도 있다. 예를 들어, 구매자는 특정 판매자에 의해 결정된 및/또는 확립된 각각의 거래에 대해 로열티 또는 판촉 포인트를 획득할 수도 있고, 그 축적된 로열티 포인트들이 보상될 수 있는 포상을 제공받을 수도 있다.

도 4 는 애플리케이션 (30) 에 의해 이용되고 지원되는, 데이터베이스 (36) 내에 유지될 수도 있는 다양한 테이블 (90) 을 나타내는, 하이-레벨 엔티티-관계도이다. 본 발명의 예시적인 실시형태는 적어도 부분적으로 관계 자료틀 (relational database) 을 이용하여 구현되는 것으로 설명되지만, 다른 실시형태들은 다른 데이터베이스-아키텍쳐 (예를 들어, 객체 지향 데이터베이스 방식) 또는 데이터 조직 구조들을 이용할 수도 있다.

유저 테이블 (92) 은 컴퓨터-기반 시스템 (12) 의 각각의 등록된 유저에 대한 레코드를 포함하고, 각각의 이러한 등록 유저에 관한 식별자, 주소 및 재정 수단 정보를 포함할 수도 있다. 일 실시형태에서, 유저는 컴퓨터-기반 시스템 (12) 내에서 저자/발행자 (예를 들어, 판매자) 및 정보 소비자 (예를 들어, 구매자) 또는 양자 모두로서 동작할 수도 있다. 본 발명의 일 실시예에서, 구매자는 축적된 가치 (예를 들어, 상업 통화 또는 전용 통화) 를 갖는 유저일 수도 있고, 그 축적된 가치를 컴퓨터-기반 시스템 (12) 에 의해 판매용으로 제공된 아이템들로 거래할 수 있다.

테이블들 (90) 은 또한, 컴퓨터-기반 시스템 (12) 을 통해 거래되거나 거래된 데 이용가능한 상품 및 서비스 (예를 들어, 아이템들) 에 대한 아이템 레코드가 유지되는 아이템 테이블 (94) 을 포함한다. 아이템 테이블 (94) 내의 각각의 아이템 레코드는, 판매자 및 하나 이상의 실제 또는 잠재적인 구매자들을 각각의 아이템 레코드와 연관시키기 위해, 유저 테이블 (92) 내의 하나 이상의 유저 레코드들과 또한 링크될 수도 있다.

검색 메타데이터 테이블 (152) 은, 아이템 정보 및 검색 정보를 분류하기 위한 검색 메타데이터 (예를 들어, 분류 규칙 및 추론 규칙), 및 브라우징 특성들을 표시하기 위한 검색 메타데이터 (예를 들어, 표시 명령들) 를 포함한다.

거래 테이블 (96) 은, 아이템 테이블 (94) 내에 레코드들이 존재하는 아이템들을 포함하는 각각의 거래 (예를 들어, 구매 거래) 에 대한 레코드를 포함한다.

주문 테이블 (98) 에는 오더 레코드들이 존재하고, 각각의 오더 레코드는 주문과 연관된다. 한편, 각각의 오더는 하나 이상의 거래에 관한 것일 수도 있고, 거래들에 대해 레코드들이 거래 테이블 (96) 내에 존재한다.

입찰 테이블 (100) 내의 입찰 레코드들 각각은, 옥션 애플리케이션 (44) 에 의해 지원되는 옥션-형식 목록과 함께 컴퓨터-기반 시스템 (12) 에서 수신되는 입찰에 관련된다. 피드백 테이블 (102) 은, 일 실시예에서, 유저들에 관한 평가 정보를 세우고 유지하기 위해 하나 이상의 평가 애플리케이션들 (50) 에 의해 이용된다. 내력 테이블 (104) 은 유저가 파티이었던 거래의 내력을 유지한다. 하나 이상의 속성 테이블들은, 아이템 테이블 (94) 내부에 레코드들이 존재하는 아 이템들에 관한 속성 정보를 기록하는 아이템 속성 테이블 (105) 및, 유저 테이블 (92) 내에 레코드들이 존재하는 유저들에 관한 속성 정보를 기록하는 유저 속성 테이블 (106) 을 포함한다.

데이터 자원 검색

도 5 는 본 발명의 일 실시형태에 따른, 데이터 자원의 검색을 용이하게 하는 시스템 (81) 을 나타내는 블록도이다. 시스템 (81) 은 이하의 것들에 대한 예시적인 개관을 제공하기 위해 설명된 것이다. 시스템 (81) 은 분류 엔진 (83), 분류 규칙 (89), 및 추론 규칙 (91) 을 포함한다. 분류 엔진 (83) 은 저자/발행자 (예를 들어, 판매자 (87)) 로부터 정보 (예를 들어, 아이템 목록 (85)) 를 수신하고, 분류 태그들 (97), 추론 태그들 (99) 을 포함하는 태깅된 (tagged) 아이템 정보 (93) (예를 들어, 태깅된 아이템 목록 (93)) 를 생성하고, 그 태깅된 아이템 정보 (93) 를 분류 엔진에 (83) 저장한다. 분류 엔진 (83) 은 분류 규칙 (89) 및 추론 규칙 (91) 을 이용하여 그 정보에 대해 분류 태그들 (97) 및 추론 태그들 (99) 을 생성하고 인가한다.

도 6 은 정보 (예를 들어, 아이템 정보) 를 분류하기 위한, 일 실시형태에 따른, 검색 애플리케이션들 (57) 및 검색 관련 데이터 구조들을 나타내는 블록도이다. 검색 애플리케이션들 (57) 은 수신 모듈 (422) 및 분류 엔진 (83) 을 포함한다. 수신 모듈 (422) 은 클라이언트 머신으로부터 유저 (예를 들어, 판매자) 에 의해 입력된 정보 또는 정보 아이템들 (예를 들어, 정보 아이템 (120)) 을 수신할 수도 있다. 수신 모듈 (422) 은 아이템 정보 (120) 에 카탈로그 정보를 부 가하여, 그 아이템 정보 (120) 를 데이터베이스에 저장하고 그 아이템 정보 (120) 를 분류 엔진 (83) 에 전달할 수도 있다. 분류 엔진 (83) 은 처리 모듈 (116), 규칙 적용 모듈 (118) 및 태깅된 정보 (예를 들어, 태깅된 아이템 정보 (93)) 를 포함한다. 태깅된 정보 (93) 는 아이템 정보 (120) 및 아이템 분류 정보 (131) 를 포함한다.

처리 모듈 (116) 은 하나 이상의 도메인들 (130) 을 아이템 정보 (120) 와 연관시키고, 각각의 도메인 (130) 에 대해 아이템 분류 정보 (131) 의 셋트를 생성한다. 마지막으로, 처리 모듈 (116) 은 아이템 정보 (120), 아이템 분류 정보 (131), 및 도메인들 (130) 을 분류 엔진 (83) 에 저장한다.

규칙 적용 모듈 (118) 은 분류 규칙들 및 추론 규칙들을 적용하여 분류 태그들 (97) 및/또는 추론 태그들 (99) 을 생성하고, 이는 아이템 분류 정보 (131) 에 저장된다.

아이템 정보 (120) 는 제목 (122), 설명 (124), 하나 이상의 목록 카테고리들 (126), 하나 이상의 선택적 아이템 명세들 (128), 가격 정보 (101), 판매 형식 (103), 지불 방법 (121), 운송 정보 (123), 아이템 위치 (125), 구매자 요구들 (127), 및 부가 정보 (145) 를 포함한다. 제목 (122) 은 아이템 정보 (120) 에 대한 제목을 제공하기 위해 유저에 의해 입력된 문자 숫자식의 스트링들의 형식의 정보를 포함할 수도 있다. 설명 (124) 은 문자 숫자의 스트링들, 그림 (예를 들어, JPEG, MPEG 등) 도해 등의 형태의 정보를 포함할 수도 있다. 목록 카테고리 (126) 는 컴퓨터-기반 시스템 (12) 상에 아이템 정보 (120) 의 목록을 작성하 기 위해 유저에 의해 선택된 하나 이상의 목록 카테고리들을 포함할 수도 있다. 아이템 명세 (item specific; 128) 은 속성 (132) 및 값 (134) 을 포함하는 것으로 나타내어져 있다. 값 (134) 은 풀 다운 메뉴로부터 유저에 의해 입력될 수도 있다. 실예로서, 신발에 관련된 정보 (120) 는 신발 제조사들 (예를 들어, Reebok, Nike 등) 의 브랜드에 대응하는 상이한 값들 (134) 을 목록으로 나열하는 풀 다운 메뉴를 포함하는 아이템 명세 (128) "브랜드" 와 연관될 수도 있다. 가격 정보 (101) 는 옥션에 대한 시작가, 옥션에 대한 선택적 예비가 (예를 들어, 판매자가 그 가격 아래로는 그들의 아이템을 판매하기를 거부하는 가격), 판매자가 즉시 아이템을 판매할 가격 (예를 들어, 매점 타입의 목록), 또는 다른 가격 관련 정보를 포함할 수도 있다. 판매 형식 (103) 은 아이템이 어떻게 판매되는 지를 특정하는 정보 (예를 들어, 고정가 판매 형식, 옥션 형식, 영어, 네델란드어, 비크리 (Vickrey), 중국어, 더블, 리버스 (reverse) 옥션 등을 포함하는 옥션 타입들), 아이템이 판매 또는 옥션에 이용가능할 수도 있는 기간, 및 다른 판매 형식 정보를 포함할 수도 있다. 지불 방법 (121) 은 판매자가 수용할 지불 방법(들) (예를 들어, 지불 서비스(들), 신용 카드(들), 수표, 현금 주문 등) 을 특정하는 정보를 포함할 수도 있다. 운송 정보 (123) 는 판매자 운송 조건 (예를 들어, 누가 지불할 것인가, 판매자가 아이템을 운송할, 또는 운송하지 않을 수도 있는 위치들 등) 을 특정하는 정보를 포함할 수도 있다. 아이템 위치 (125) 는 아이템이 선적되거나 픽업될 물리적 위치를 특정하는 정보를 포함할 수도 있다. 구매자 조건들 (127) 은, 구매자가 특정 지불 서비스를 이용하는지 여부, 구매자가 특정 신 용 카드를 이용하는 지 여부, 구매자가 특정 나라에 등록되었는지 여부, 구매자 평가 (예를 들어, 구매자가 옥션에서 아이템을 구매 또는 획득 및 아이템에 대해 지불하지 않은 것으로 식별되어 1, 2, 3, 또는 더 낮은 피드백 점수를 갖는다), 및 다른 관련 정보와 같은 기준에 기초하여 어느 구매자가 목록에 있는 아이템을 구입 또는 입찰하는 것이 차단될 것인지를 특정하는 정보를 포함할 수도 있다.

수신된 정보 (예를 들어, 아이템 정보 (120)) 는 보충 정보 (예를 들어, 분류 정보 (131)) 로 보충될 수도 있다. 아이템 분류 정보 (131) 의 예에는 도메인 (130), 분류 태그들 (97), 및 추론 태그들 (99) 이 포함될 수도 있다. 예시적인 도메인들 (130) 에는, "신발", "장난감", "책" 들이 포함될 수도 있다. 각각의 분류 태그 (97) 는 태깅된 개념 (136) 및 태깅된 값 (138) 을 포함할 수도 있다. 예를 들어, 도메인 (130) "신발" 에 대한 예시적인 태깅된 개념 (136) 은 "브랜드" 를 포함할 수도 있고, 대응하는 예시적인 태깅된 값들 (138) 은 "Nike", "Reebok" 및 "Adidas" 를 포함할 수도 있다. 분류 태그들 (97) (예를 들어, 분류 정보) 의 태깅된 아이템 정보 (93) 에의 부가는 아이템 정보 (120) 를 구조화하고, 일 실시형태에서, (예를 들어, 구매자의 관점에서, 구매자의 언어로 등) 아이템 정보 (120) 의 개념적 검색을 가능하게 한다.

각각의 추론 태그 (99) 는 추론 개념 (141) 및 추론 값 (143) (예를 들어, 추론 정보) 를 포함할 수도 있다. 추론 태그 (99) 는 아이템 정보 (120) 또는 분류 태그들 (97) 에 기초하여 아이템 분류 정보 (131) 에 부가될 수도 있다. 예를 들어, 분류 엔진 (83) 은 아이템 정보 (120) 로부터 추론할 수도 있고, Corning 사가 미국에서 유리를 제조하기 때문에 Corning 사에 의해 제조된 유리 아이템은 미국에 "원산지" 를 갖는다 (예를 들어, 추론 개념 141 = "원산지", 추론 값 143 = "북아메리카"). 추론 태그 (99) 는 태깅된 개념 (136) 또는 태깅된 값 (138) 을 넓히기 위해 이용될 수도 있고, 이에 의해 정보 (예를 들어, 아이템 정보 (120) 에 의해 설명되는 아이템 목록) 에 공통의 갖심을 나눔에도 불구하고 동일 언어로 대화할 수 없을 수도 있는 유저들 (예를 들어, 구매자 또는 판매자) 을 함께 하게 할 수도 있다. 예를 들어, 판매자는 아이템 정보 (120) 내의 아이템을 "루비색 슬리퍼" 로 설명할 수도 있다. 그러나, 구매자는 "빨간색 슬리퍼" 에 대해 검색할 수도 있다. 이 예에서, 분류 엔진 (83) 은 태깅된 개념 (136) "컬러" 및 태깅된 값 (138) "루비색" 을 갖는 분류 태그 (97) 에 기초하여 추론 개념 (141) "컬러" 및 추론 값 (143) "빨간색" 을 갖는 추론 태그 (99) 를 부가할 수도 있다.

도 7 은 일 실시형태에 따른, 검색 메타데이터 (152) 를 나타내는 블록도이다. 검색 메타데이터 (152) 는 컴퓨터-기반 시스템 (12) 에서 정의될 수도 있는 각각의 도메인 (130) 에 대한 엔트리를 포함하는 것으로 나타내어져 있다. 각각의 도메인 (130) 은 한 셋트의 분류 규칙들 (89), 한 셋트의 추론 규칙들 (91), 및 도메인 쿼리 (158) 와 연관된다. 각각의 분류 규칙 (89) 은 표현 (예를 들어, 불리언) 을 포함하는 분류 구문 (133), 및 분류 구문 (133) 이 참이라고 평가한다면 실행될 수도 있는 분류 술어 (classification predicate; 135) 를 포함할 수도 있다. 분류 술어 (135) 는 전술한 바와 같이 분류 개념 (140) 및 분류 값 (142) (예를 들어, 분류 정보) 를 포함하는 것으로 나타내어져 있다. 분류 규칙 (89) 은 분류 태그 (97) (예를 들어, 분류 개념 (140) 및 분류 값 (142)) 를 적용하기 위해 분류 엔진 (83) 에 의해 이용될 수도 있다. 예를 들어, 분류 엔진 (83) 은 분류 구문 (133) 에 기초하여 아이템 정보 (120) 를 검색할 수도 있고, 분류 구문 (133) 이 참이라고 평가하면 (예를 들어, 제목이 "루비색" 을 포함한다면), 분류 엔진 (83) 은 분류 술어 (135) 를 실행할 수도 있다. 본 실시예에서, 분류 술어 (135) 는 대응하는 아이템 정보 (120) 에 분류 개념 (140) 및 분류 값 (142) 을 태그로 붙인다 (예를 들어, 컬러 = 루비색). 이후, 분류 개념 (140) 및 분류 값 (142) 은 태깅된 아이템 정보 (93) 와 관련하여 태깅된 개념 (136) 및 태깅된 값 (138) (예를 들어, 컬러 = 루비색) 으로서 각각 조회될 수도 있다.

각각의 추론 규칙 (91) 은, 표현 (예를 들어, 불리언) 을 포함할 수도 있는 추론 구문 (137) 과, 그 추론 구문 (137) 이 참이라고 평가하면 실행될 수도 있는 추론 술어 (139) 를 포함할 수도 있다. 추론 술어 (139) 는 전술한 바와 같이 추론 개념 (141) 및 추론 값 (143) (예를 들어, 추론 정보) 을 포함하는 것으로 나타내어져 있다. 추론 규칙 (91) 은 추론 태그 (99) (예를 들어, 추론 개념 (141) 및 추론 값 (143)) 을 적용하기 위해 분류 엔진 (83) 에 의해 이용될 수도 있다. 예를 들어, 분류 엔진 (83) 은 추론 구문 (137) 을 이용하여 아이템 정보 (120) 및 분류 태그들 (97) 을 평가할 수도 있다. 추론 구문 (137) 이 참이라고 평가하면 (예를 들어, 설명 (120) 이 "빨간색" 을 포함하거나, OR 태깅된 개 념 (140)-태깅된 값 (138) 이 "컬러 = 빨간색" 을 포함한다면), 추론 술어 (139) 가 실행되어, 본 실시예에서는 대응하는 아이템 정보 (120) 에 부가 정보 (예를 들어, 추론 개념 (141) 및 추론 값 (143)) (예를 들어, 컬러 = 루비색) 를 태그로 붙일 수도 있다. 이후, 그 부가된 추론 개념 (141) 및 추론 값 (143) 은 태깅된 아이템 정보 (93) 와 관련하여 추론 태그 (99) 로서 집합적으로 조회될 수도 있다.

도메인 쿼리 (158) 는 대응하는 도메인 (130) 에 포함된 아이템 정보 (120) 를 식별하기 위해 이용될 수도 있다. 도메인 쿼리 (153) 는 표현 (예를 들어, 불리언) 과, 표현이 참이라고 평가하면, 대응하는 태깅된 아이템 정보 (93) 와 연관될 수도 있는 도메인 (130) 을 포함할 수도 있다. 도메인 쿼리 (153) 는 컴퓨터 프로그램 또는 관리자에 의해 디자인될 수도 있다. 예를 들어, 도메인 "신발" 과 연관된 표현 (예를 들어, 불리언) 이 'Nike' 를 포함하는 설명 (124) 및 '신발' 을 포함하는 제목 (122) 을 요구할 수도 있다. 다른 실시형태는, "거래" 을 나타내는 값 (134) 와 연관된 아이템 명세 (128), 또는 "운동화" 를 나타내는 목록 카테고리 (126) 를 또한 요구하는 표현 (예를 들어, 불리언) 을 포함할 수도 있다.

도 8 은 데이터 자원 검색을 용이하게 하기 위한 방법의 일 실시형태 (160) 를 나타내는 플로우차트이다. 클라이언트 머신 (22) 에 의해 수행되는 동작들이 좌측에 나타내어져 있고, 애플리케이션 서버 (28) 에 의해 수행되는 동작이 우측에 나타내어져 있다.

동작 162 에서의 상거래에서, 클라이언트 머신 (22) 에서의 판매자는 아이템 정보 (120) (예를 들어, 아이템 목록) 를 입력하고, 이는 애플리케이션 서버 (28) 로 전달되고, 이 애플리케이션 서버 (28) 는 (예를 들어, 동작 164 에서) 그 아이템 정보 (120) 를 수신한다. 도 30 은 예시적인 아이템 정보 (120) 를 표시하는 유저 인터페이스 화면 (165) 의 일 실시형태를 나타낸다. 아이템 정보 (120) 는 제목 (122), 목록 카테고리 (126), 아이템 명세 (128), 및 ISBN 넘버 (예를 들어, 123456) 를 포함하는 설명 (124) 을 포함한다. 예를 들어, 제목 (122) 은 유저가 선택한 제목 "The Cat in the Hat Strikes Back" 일 수도 있다. 목록 카테고리 (126) 는 유저가 목록 카테고리 "아동 도서" 를 선택하였다는 것을 보여준다. 다른 실시형태는 유저가 다수의 목록 카테고리들 (126) (예를 들어, 책, 장난감, 어린이용 고전 등) 을 입력 또는 선택하였다는 것을 보여줄 수도 있다. 아이템 명세 (128) 는 "새로운" 책이라는 조건을 더 나타낼 수도 있다. "새로운" 이라는 값은 "오래된", "중고의", "양호한" 등을 포함하는 다수의 값들을 포함하는 풀 다운 메뉴로부터 선택된 것일 수도 있다. ISBN 넘버 (예를 들어, 123456) 는 부가 정보를 부가하도록 하는데 이용될 수도 있다.

도 8 로 돌아와서, 동작 166 에서, 수신 모듈 (422) 은 카탈로그 정보의 아이템 정보 (120) 에의 부가를 야기할 수도 있는 스트링들, 값들, 또는 다른 정보 아이템들을 식별하기 위해 아이템 정보 (120) (예를 들어, 제목 (122), 설명 (124), 목록 카테고리 (126), 아이템 명세 (128) 등) 를 검색한다. 예를 들어, ISBN 넘버는 적절한 카테고리로부터 정보(예를 들어, 문자 숫자식의 텍스트 그래픽, 그림, 오디오, 멀티-미디어 등) 의 부가를 트리거할 수도 있다. 사실, ISBN 넘버는 유일하게 "The Cat in the Hat Strikes Back" 이라는 책을 식별하고, 따라서, 그 책을 더 설명할 수도 있는 카탈로그로부터의 정보 (예를 들어, 저자명, 페이지수, 발행자, 새책의 가격 목록, 저자의 그림, 제 1 장의 음성 레코딩 등) 를 포함하도록 하는 트리거를 제공할 수도 있다. 다른 실시형태는 추가적인 정보를 부가하기 위한 트리거를 제공할 수도 있는 정보 (예를 들어, 통일 상품 넘버 (Universal Product Number), 통일 상품 코드 (Universal Product Code), 고유 명사 등) 를 식별하기 위해 이용될 수도 있는 카탈로그들의 다른 타입들을 포함할 수도 있다. 다른 실시형태에서, 카탈로그정보의 부가는 판매자가 그 아이템에 대한 정보를 입력하는 시간에서 아이템이 제출되기 전에 수행될 수도 있다.

동작 168 에서, 수신 모듈 (422) 은 아이템 정보 (120) 를 데이터베이스 (36) 에 저장하고, 이 아이템 정보 (120) 를 분류 엔진 (83) 에 전달한다. 동작 170 에서, 처리 모듈 (116) 은 태깅된 아이템 정보 (93) 를 분류 엔진 (83) 에서 생성하고, 그 아이템 정보 (120) 를 태깅된 아이템 정보 (93) 에 저장한다. 그 다음, 처리 모듈 (116) 은 검색 메타데이터 (158) 로부터 도메인 쿼리 (158) 를 판독한다.

판정 동작 172 에서, 처리 모듈 (116) 은 유저에 의해 입력된 아이템 정보 (120) 에 의해 설명되는 아이템이, 아이템 정보 (120) 에 대해 도메인 쿼리 (158) 와 연관된 표현 (예를 들어, 불리언) 을 평가함으로써 도메인 쿼리 (158) 를 이용하여 발견된다. 표현 (예를 들어, 불리언) 이 참이라고 평가하면, 브랜치는 동작 174 로 간다. 그렇지 않으면 브랜치는 판정 동작 180 으로 간다.

동작 174 에서, 처리 모듈 (116) 은 아이템 정보 (120) 를 현재 도메인 (130) 에 포함되도록 등록한다. 예를 들어, 처리 모듈 (116) 은 태깅된 아이템 정보 (93) 와 연관된 아이템 분류 정보 (131) 에 도메인 (130) 을 저장함으로써 아이템 정보 (120) 를 등록할 수도 있다.

동작 176 에서, 규칙 적용 모듈 (118) 은 분류 규칙 (89) 을 태깅된 아이템 정보 (93) 와 연관된 아이템 정보 (120) 에 적용한다.

도 9 는 분류 규칙에 따라 정보를 평가하기 위한 방법의 일 실시형태 (186) 를 나타낸다. 방법 (186) 은 동작 188 에서 구칙 적용 모듈 (118) 이 현재 도메인 (130) 에 기초하여 검색 메타데이터 (152) 로부터 그 다음 분류 규칙 (89) 을 판독하고 선택하면서 시작한다.

판정 동작 190 에서, 규칙 적용 모듈 (118) 은 아이템 정보 (120) (예를 들어, 제목 (122), 설명 (124), 목록 카테고리 (126), 아이템 명세 (128) 등) 를 평가하기 위해 분류 규칙 (89) 과 연관된 분류 구문 (133) (예를 들어, '제목이 "루비색" 을 포함한다면') 을 이용한다. 분류 구문 (133) 이 참이라고 평가한다면, 브랜치는 동작 200 으로 간다. 그렇지 않으면, 브랜치는 판정 동작 202 로 간다.

동작 200 에서, 규칙 적용 모듈 (118) 은 태깅된 아이템 정보 (93) 에 대해 분류 규칙 (89) 과 연관된 분류 술어 (135) (예를 들어, 컬러 = 루비색) 를 실행한다. 예를 들어, 규칙 적용 모듈 (118) 은 분류 술어 (135) 를 태깅된 아이템 정보 (93) 로서 부착하거나 저장할 수도 있다. 분류 술어 (135) 는 이후에 태 깅된 아이템 정보 (93) 와 관련하여 분류 태그 (97) (예를 들어, 컬러 = 루비색) 로서 조회될 수도 있다.

판정 동작 202 에서, 규칙 적용 모듈 (118) 은 현재 도메인 (130) 에 더 많은 분류 규칙들 (89) 이 존재하는지 여부를 판정한다. 만약, 더 많은 분류 규칙들 (89) 이 존재한다면, 브랜치는 동작 188 로 간다. 그렇지 않으면, 방법 (186) 은 종료한다.

도 8 로 다시 돌아와서, 동작 178 에서, 규칙 적용 모듈 (118) 은 추론 규칙 (91) 을 태깅된 아이템 정보 (93) 와 연관된 분류 태그들 (97) 에 적용한다.

도 10 은 추론 규칙들 (99) 에 따라 정보를 평가하기 위한 방법의 일 실시형태 (204) 를 나타내는 블록도이다. 동작 206 에서 시작하여, 규칙 적용 모듈 (118) 은 현재 도메인 (130) 에 기초하여 검색 메타데이터 (152) 로부터 그 다음 추론 규칙 (91) 을 판독하고 선택한다.

동작 208 에서, 규칙 적용 모듈 (118) 은 현재 도메인 (130) 과 연관된 (예를 들어, 분류 태그들 (97) 을 포함하는) 그 다음 태깅된 아이템 정보 (93) 를 판독한다. 판정 동작 210 에서, 규칙 적용 모듈 (118) 은 아이템 정보 (120) (예를 들어, 제목 (122), 설명 (124), 목록 카테고리 (126), 아이템 명세 (128)) 및 분류 태그들 (97) (예를 들어, 컬러 = 빨간색) 을 평가하기 위해 추론 규칙 (91) 과 연관된 추론 구문 (137) (예를 들어, "설명이 '루비색' 을 포함 OR 컬러 = 루비색이라면") 을 이용한다. 추론 구문 (137) 이 참이라고 평가하면, 브랜치는 동작 212 로 간다. 그렇지 않으면, 브랜치는 판정 동작 (214) 으로 간다.

동작 212 에서, 규칙 적용 모듈 (118) 은 태깅된 아이템 정보 (93) 에 대해 추론 규칙 (91) 과 연관된 추론 술어 (139) (예를 들어, 컬러 = 빨간색) 를 실행한다. 예를 들어, 추론 술어 (139) 는 태깅된 아이템 정보 (93) 에 부가되거나 부착될 수도 있다. 이후에, 추론 술어 (139) 는 태깅된 아이템 정보 (93) 와 관련하여 추론 태그 (99) 로서 조회될 수도 있다.

판정 동작 (214) 에서, 규칙 적용 모듈 (118) 은 더 많은 태깅된 아이템 정보 (93) 가 현재 도메인 (130) 과 연관되어 있는지 여부를 판정한다. 만약 더 많은 태깅된 아이템 정보 (93) 가 존재한다면, 브랜치는 동작 208 로 간다. 그렇지 않으면, 브랜치는 판정 동작 (216) 으로 간다.

판정 동작 216 에서, 규칙 적용 모듈 (118) 은 더 많은 추론 규칙들 (91) 이 현재 도메인 (130) 과 연관될 수도 있는지 여부를 판정한다. 규칙 적용 모듈 (118) 이 더 많은 추론 규칙들 (91) 이 존재한다고 판정한다면, 브랜치는 동작 206 으로 간다. 그렇지 않으면, 프로세싱은 종료한다.

도 8 로 다시 돌아가서, 동작 180 에서, 처리 모듈 (116) 은 더 많은 도메인들 (130) 이 존재하는지 여부를 판정한다. 처리 모듈 (116) 이 더 많은 도메인들 (130) 이 존재한다고 판정하면, 브랜치는 동작 170 으로 간다. 그렇지 않으면, 방법 (160) 은 종료한다.

분류 엔진 (83) 의 다른 실시형태는 단일 불리언 평가 그래프를 포함할 수도 있다. 불리언 평가 그래프는 불리언 평가의 성능을 향상시키기 위해 분류 엔진 (83) 에 의해 이용될 수도 있다. 예를 들어, 불리언 평가 그래프는, 분류 엔진 (83) 에 의해서 계산되는 평가 이벤트들의 총 수를 최소화하면서 큰 셋트의 정보 (예를 들어, 아이템 목록들 (85)) 에 대해 큰 셋트의 분류 규칙들 (89) 및 추론 규칙들 (91) 을 평가할 수도 있다.

쿼리 생성

도 11 은 데이터 자원을 검색하는 쿼리를 생성하기 위한 시스템의 일 실시형태 (107) 를 나타내는 블록도이다. 시스템 (107) 은 이하의 것들에 대한 예시적인 개관을 제공하기 위해 설명된다. 시스템 (107) 은 검색 애플리케이션들 (57) 및 분류 규칙들 (89) 을 포함한다. 검색 애플리케이션들 (57) 은 구매자 (119) 로부터 키워드 쿼리 (109) 를 수신하고, 도메인 (130) 을 결정하기 위해 분류 규칙들 (89) 을 이용함으로써 응답하고, 개념 쿼리 (111) 를 생성하고, 가능하다면 구매자 (119) 에게 다시 전달되는 각각의 키워드들을 결정한다. 개념 쿼리 (111) 는 분류 규칙들 (89) 에 의해 결정되는 바와 같이 키워드 쿼리 (109) 의 키워드들에 대응하는 하나 이상의 선택된 특성들 (113) (예를 들어, 분류 정보) 을 포함한다. 일부 예에서, 키워드 쿼리 (109) 의 키워드들은 선택된 특성들 (113) 에 대응하지 않을 수도 있고, 다시 그대로 구매자에게 전달될 수도 있다. 각각의 선택된 특성 (113) 은 선택된 개념 (115) 및 선택된 값 (117) 을 포함한다.

도 12 는 일 실시예에 따른, 검색 애플리케이션들 (57) 및 검색 메타데이터 (152) 를 나타내는 블록도이다. 검색 애플리케이션들 (57) 은 계산 모듈 (221) 및 쿼리 생성 모듈 (223) 을 포함한다. 계산 모듈 (221) 은 구매자 (119) 로부 터 키워드 쿼리 (109) 를 수신하고, 유저 인터페이스를 개념 쿼리 (111) 및 도메인 (130) 을 포함하는 구매자 (119) 로 다시 전달한다. 쿼리 생성 모듈 (223) 은 키워드 쿼리 (109) 의 도메인 (130) 을 결정하고, 분류 규칙 (89) 을 키워드 쿼리 (109) 에 적용하여 개념 쿼리 (111) 를 생성하고, 가능하면 키워드들을 식별한다.

검색 메타데이터 (152) 는 전술한 바와 같이 컴퓨터-기반 시스템 (12) 에 대해 정의된 도메인들 (130) 모두를 포함할 수도 있다. 각각의 도메인 (130) 은 도메인 구문 (129) 및 분류 규칙들 (89) 과 연관될 수도 있다. 도메인 구문 (129) 은 키워드 쿼리 (109) 를 평가하기 위해 이용될 수도 있는 표현 (예를 들어, 불리언) 을 포함한다. 도메인 구문이 참이라고 평가한다면, 키워드 쿼리는 도메인 (130) 과 연관될 수도 있다. 각각의 분류 규칙 (89) 은 전술한 바와 같이 분류 구문 (133) 및 분류 술어 (135) 를 포함한다. 분류 구문 (133) 은 키워드 쿼리 (109) 의 키워드를 평가하기 위해 이용될 수도 있는 표현 (예를 들어, 불리언) 을 포함한다. 분류 구문 (133) 이 참이라고 평가한다면, 분류 술어 (135) (예를 들어, 분류 개념 (140) 및 분류 값 (142)) 가 키워드 쿼리 (109) 에 대해 실행되어, 분류 개념 (140) 및 분류 값 (142) (예를 들어, 분류 정보) 을 키워드 쿼리 (109) 의 키워드(들) 과 연관시킨다.

도 13 은 데이터 자원을 검색하기 위한 쿼리를 생성하는 방법의 일 실시형태 (220) 를 나타내는 블록도이다. 클라이언트 머신 (22) 에 의해 수행되는 동작들은 좌측에 나타내었고, 애플리케이션 서버 (28) 상에서 수행되는 동작들은 우측에 나타내었다. 방법 (220) 은 동작 222 에서 시작하고, 유저는 키워드 쿼리 (109) 를 입력한다.

도 31 은 키워드 쿼리를 수신하기 위한, 일 실시형태에 따른, 유저 인터페이스 (224) 를 나타낸다. 유저 인터페이스 (224) 는 키워드 쿼리 (109) 를 입력하기 위해 구매자 (119) 에 의해 이용될 수도 있는 대화 박스 (226) 를 포함한다. 대화 박스 (226) 는 키워드 쿼리 (109) "Nike 검정색 사이즈 8" 를 포함하는 것으로 나타내어져 있다. 키워드 쿼리 (109) 는 키워드들 (228), "Nike", "검정색", 및 "사이즈 8" 을 포함한다. 키워드들 (228) 은 하나 이상의 워드들 또는 문자 숫자식 표현들 (예를 들어, 사이즈 8) 을 포함할 수도 있을 것으로 여겨진다. 본 예시적인 유저 인터페이스는 유저가 수동으로 도메인 (130) 을 식별할 것을 요구하지 않지만, 다른 실시형태는 유저에 의해 입력되는 키워드 쿼리 (109) 와 연관될 수도 있는 도메인 (130) 을 유저가 수동으로 식별할 것을 요구하는 유저 인터페이스를 포함할 수도 있다. 예를 들어, 일 실시형태에서, 유저는 특정 도메인 (130) 과 연관될 수도 있는 키워드 쿼리 (109) 를 입력하는 대화 박스 (226) 를 위치시키기 위해 트리 구조를 네비게이트할 필요가 있을 수도 있다.

도 13 으로 돌아가서, 동작 230 에서, 계산 모듈 (221) 은 키워드 쿼리 (109) 를 수신하고, 그 키워드 쿼리 (109) 를 쿼리 생성 모듈 (223) 로 전달하고, 이 쿼리 생성 모듈 (223) 은 그 키워드 쿼리 (109) 가 하나 이상의 도메인들 (130) 과 연관될 수도 있는지 여부를 판정한다.

도 14 는 키워드 쿼리 (109) 에 기초하여 도메인들 (130) 을 판정하기 위한 방법의 일 실시형태 (230) 를 나타낸다. 방법 (230) 은 동작 233 에서 시작하 며, 쿼리 생성 모듈 (223) 은 검색 메타데이터 (152) 로부터 그 다음 도메인 구문 (129) 을 판독한다. 도메인 구문 (129) 은 표현 (예를 들어, 불리언) 을 포함할 수도 있다.

판정 동작 (236) 에서, 쿼리 생성 모듈 (223) 은 표현 (예를 들어, 불리언)을 포함할 수도 있는 도메인 구문 (129) 을 이용하여 키워드 쿼리 (109) 를 평가한다. 만약 표현 (예를 들어, 불리언)이 참이라고 평가한다면, 브랜치는 동작 238 로 간다. 그렇지 않다면 브랜치는 판정 동작 (242) 으로 간다.

동작 238 에서, 쿼리 생성 모듈 (223) 은 도메인 (130) 을 개념 쿼리 (239) 에 등록함으로써 도메인 (130) 을 개념 쿼리 (239) 와 연관시킨다.

판정 동작 (242) 에서, 쿼리 생성 모듈 (223) 은 처리할 더 많은 도메인 구문 (129) 이 있는지 여부를 판정한다. 처리할 더 많은 도메인 구문들 (129) 이 존재한다면, 브랜치는 동작 233 으로 간다. 그렇지 않으면, 프로세싱은 종료한다.

도 13 으로 돌아 가서, 판정 동작 249 에서, 계산 모듈 (221) 은 키워드 쿼리 (109) 가 하나를 초과한 도메인 (130) 과 연관될 수도 있는지를 판정한다. 키워드 쿼리 (109) 가 하나를 초과한 도메인과 연관될 수도 있다면, 브랜치는 동작 250 으로 간다. 그렇지 않으면, 브랜치는 동작 252 로 간다.

동작 250 에서, 계산 모듈 (221) 은 유저가 키워드 쿼리 (109) 와 연관된 도메인들 (130) 로부터 하나의 도메인 (130) 을 선택하도록 하는 요청을 전달한다.

동작 254 에서, 클라이언트 머신 (22) 에서, 도메인 (130) 의 유저-선택이 가능하도록 유저 인터페이스가 표시될 수도 있다. 도 32 는 도메인 (130) 을 선택하기 위한, 일 실시예에 따른, 유저 인터페이스 (256) 를 나타낸다. 유저 인터페이스 (256) 는 유저에 의해 선택될 수도 있는 도메인들 (130) (예를 들어, "신발", "조깅복", 및 "골프 용품") 및 키워드 쿼리 (109) 을 포함한다.

도 13 으로 돌아가서, 클라이언트 머신 (22) 에서, 동작 260 에서, 유저는 "신발" 도메인 (130) 을 선택하고, 이 선택은 애플리케이션 서버 (28) 로 전달된다.

동작 252 에서, 애플리케이션 서버 (28) 에서, 쿼리 생성 모듈 (231) 은 "신발" 도메인 (130) 을 수신하고, 그 "신발" 도메인 (130) 및 키워드 쿼리 (109) "Nike 검정색 사이즈 8" 을 이용하여 선택된 특성들 (113) 을 판정한다.

도 15 는 키워드 쿼리 (109) 및 도메인 (130) 에 기초하여 선택된 특성들 (113) 을 판정하기 위한 방법의 일 실시형태 (252) 를 나타내는 블록도이다. 방법 252 는 동작 262 에서 시작하고, 쿼리 생성 모듈 (223) 은 검색 메타데이터 (152) 로부터 분류 규칙 (89) 을 판독하기 위해 키워드 쿼리 (109) 와 연관된 도메인 (130) 을 활용한다.

판정 동작 264 에서, 쿼리 생성 모듈 (223) 은 키워드 쿼리 (109) 의 가장 긴 셋트의 키워드들 (예를 들어, 워드들) 을 평가하기 위해 분류 규칙 (89) 과 연관된 분류 구문 (133) 을 이용한다. 분류 구문 (133) 이 참이라고 평가한다면, 브랜치는 동작 266 으로 간다. 그렇지 않으면, 브랜치는 동작 265 로 간다.

동작 265 에서, 쿼리 생성 모듈 (223) 은 키워드 쿼리 (109) 로부터 제 1 키워드를 제거한다.

동작 266 에서, 쿼리 생성 모듈 (223) 은 분류 규칙 (89) 과 연관된 분류 술어 (135) (예를 들어, 컬러 = 루비색) 을 개념 쿼리 (239) 에 등록한다. 이후, 분류 술어 (135) 는 선택된 특성들 (113) 로서 조회될 수도 있다.

동작 267 에서, 쿼리 생성 모듈 (223) 은 키워드 쿼리 (109) 로부터 참이라고 평가된 키워드(들) (228) 을 제거한다.

판정 동작 269 에서, 쿼리 생성 모듈 (223) 은 키워드 쿼리 (109) 내에 더 많은 키워드들이 존재하는지를 판정한다. 만약 더 많은 워드들이 존재한다면, 브랜치는 판정 동작 264 로 간다. 그렇지 않으면, 브랜치는 판정 동작 (268) 으로 간다.

판정 동작 (268) 에서, 쿼리 생성 모듈 (223) 은 더 많은 분류 규칙들 (89) 이 존재하는지를 판정한다. 만약 더 많은 분류 규칙들 (89) 이 존재하다면, 브랜치는 동작 (262) 으로 가서 전체 키워드 쿼리 (109) 를 평가한다. 그렇지 않으면, 방법 (252) 은 종료한다.

도 13 으로 돌아가서, 동작 270 에서, 애플리케이션 서버 (28) 에서, 계산 모듈 (221) 은 키워드 쿼리 (109), 도메인 (130), 및 개념 쿼리 (239) 를 포함하는 유저 인터페이스를 클라이언트 머신 (22) 의 구매자 (119) 에게 전달한다.

동작 272 에서, 클라이언트 머신 (22) 에서, 유저 인터페이스가 유저에게 표시된다. 도 33 은 키워드 쿼리 (109), 도메인 (130), 및 개념 쿼리 (239) 를 표시하기 위한, 일 실시예에 따른, 인터페이스 (278) 를 나타낸다. 유저 인터페이스 (278) 는 키워드 쿼리 (109) "Nike 검정색 사이즈 8", 및 3 개의 선택된 특 성들 (113) "컬러 - 검정색", "브랜드 - Nike", 및 "신발 사이즈 - 8" 을 포함하는 개념 쿼리 (111) 를 포함하는 것으로 나타내어져 있다. 선택된 특성들 (113) 은 각각 선택된 개념들 (115) (예를 들어, "컬러", "브랜드", "신발 사이즈") 및 선택된 값들 (117) (예를 들어, "검정색", "Nike", 및 "8") 을 포함하는 것으로 나타내어져 있다. 다른 실시예는 키워드(들) (예를 들어, 분류 구문 (133) 과 관련하여 참이라고 평가될 수 없을 수도 있는 키워드 쿼리 (109) 에 포함된 키워드들 (228)) 을 포함할 수도 있다.

키워드 쿼리를 수신하여 개념 쿼리, 도메인, 키워드들을 생성하는 시스템의 다른 실시형태는 단일 불리언 평가 그래프를 포함할 수도 있다. 불리언 평가 그래프는 불리언 평가들의 성능을 향상시키기 위해 시스템에 의해 이용될 수도 있다. 예를 들어, 시스템은, 시스템 (107) 에 의해 계산되는 평가 이벤트들의 총 수를 최소화하면서 키워드 쿼리 (109) 에 대해 큰 셋트의 분류 규칙들 (89) 을 평가하기 위해 불리언 평가 그래프를 이용할 수도 있다.

데이터 아이템 식별 & 특성들 취소

도 16 은 일 실시형태에 따라, 키워드 쿼리를 수신하고 키워드 쿼리, 개념 쿼리, 브라우징 특성들 및 정보 (예를 들어, 아이템 목록들 (85)) 를 포함하는 유저 인터페이스를 생성하는 시스템 (293) 을 나타내는 블록도이다. 시스템 (293) 은 이하의 것들에 대한 개관을 제공하기 위해 설명된다.

시스템 (293) 은 검색 애플리케이션들 (57), 분류 규칙들 (89), 및 표시 명령들 (302) 을 포함한다. 검색 애플리케이션들 (57) 은 유저 인터페이스 (295) 를 이용하여 구매자 (119) 에 의해 입력될 수도 있는 키워드들 (228) 을 포함하는 키워드 쿼리 (109) "Nike 검정색 사이즈 8" 을 수신하는 것으로 나타내어져 있다. 검색 애플리케이션들 (57) 은 키워드 쿼리 (109) 를 수신하고, 분류 규칙들 (89) 및 표시 명령들 (302) 을 이용하여 유저 인터페이스 (297) 를 생성한다.

유저 인터페이스 (297) 는 키워드 쿼리 (109), 도메인 (130) "신발", 개념 쿼리 (111) "컬러 - 검정색, 브랜드 - Nike, 신발 사이즈 - 8", 다수의 브라우징 셋트들 (303) (예를 들어, "제품 타입", "신발 스타일", "가격 범위") 및 그 개념 쿼리에 기초하여 발견되는 정보 (예를 들어, 아이템 목록들 (85)) 를 포함한다. 키워드 쿼리 (109), 도메인 (130) 및 개념 쿼리들 (111) 은 전술한 바 있다. 개념 쿼리 (111) 는 다수의 선택된 특성들 (113) (예를 들어, "컬러 - 검정색", "브랜드 - Nike", 및 "신발 사이즈 8") 을 포함하는 것으로 나타내어져 있다. 각각의 선택된 특성 (113) 은 선택된 개념 (115) (예를 들어, "컬러") 및 선택된 값 (117) (예를 들어, "검정색") 을 포함한다. 예를 들어, 구매자 (119) 는 선택된 특성들 (113) 을 개념 쿼리 (111) 에 부가하거나, 및/또는 개념 쿼리 (111) 로부터 선택된 특성들 (113) 을 취소할 수도 있다. 구매자 (119) 는 아래에서 설명되는 바와 같이 브라우징 특성을 선택함으로써 선택된 특성 (113) 을 개념 쿼리 (111) 에 부가할 수도 있다. 구매자는 각각이 특정 선택 특성 (113) 과 연관될 수도 있는 하나 이상의 "취소" 버튼들을 선택함으로써 선택된 특성들 (113) 을 취소할 수도 있다. 브라우징 셋트들 (303) 은 특정 순서에 따라 (예를 들어, 키워드 쿼리 (109), 선택된 브라우징 특성들, 및 취소들로부터 생성되는) 누적 되는 선택된 특성들 (113) 에 기초하여 검색 애플리케이션들 (57) 에 의해 선택된다. 다르게 말하면, 가장 관심 있는 브라우징 셋트들 (303) 은 가장 적은 관심을 갖는 브라우징 셋트들 (303) 앞에 제공될 수도 있고, 관심의 레벨은 관리자에 의해 구매자 (119) 의 관점에서 결정된다. 다른 실시형태들은 특정 브라우징 셋트 (303) 에 대한 구매자 관심의 레벨은 브라우징 셋트들 (303) 의 유저 선택들을 모니터링함으로써 결정할 수도 있다. 일부 실시형태는 특정 브라우징 셋트 (303) 에 대한 구매자 관심의 레벨을 구매자에 의해 이루어지는 브라우징 셋트들 (303) 의 이전 선택들을 모니터링함으로써 결정할 수도 있다. 각각의 브라우징 셋트 (303) 는 브라우징 개념 (284) (예를 들어, "제품 타입") 및 다수의 브라우징 값들 (286) (예를 들어, "남자 신발", "여자 신발" 들) 을 포함하는 것으로 나타내어져 있다. 구매자 (119) 는 하나 이상의 브라우저 값들 (286) (예를 들어, "남자 신발") 을 선택하고, 그에 의해 효과적으로 브라우징 특성 (287) (예를 들어, "제품 타입 - 남자 신발") 을 선택할 수도 있다. 이후에, 선택된 브라우징 특성 (287) 은 누적되는 선택된 특성들 (113) 에 포함될 수도 있는 선택된 특성 (113) 로서 조회될 수도 있고, 이는 브라우징 셋트들 (303)을 선택하고, 카운트를 세고, 정보 (예를 들어, 아이템 목록들 (85)) 을 발견하는데 이용될 수도 있다.

도 17 은 일 실시형태에 따른, 검색 애플리케이션 (57) 및 검색 메타데이터 (152) 를 나타내는 블록도이다. 검색 애플리케이션들 (57) 은 결정 모듈 (298) 및 생성 모듈 (300) 을 포함한다. 결정 모듈 (298) 은 선택된 특성들 (113) 을 결정하고, 정보 (예를 들어, 아이템 목록들 (85), 브라우징 셋트들 (303) 등) 를 표시하기 위한 유저 인터페이스 상의 면적의 크기를 결정하고, 표시할 정보 (예를 들어, 아이템 목록들 (85)) 을 결정하고, 표시할 브라우징 셋트들 (301) 을 결정한다. 결정 모듈 (298) 은 (예를 들어, 키워드 쿼리 (109) 로부터 생성되는) 개념 쿼리 (111) 에 기초한 선택된 특성들 (113), 선택될 수도 있는 브라우징 특성(들) (287), 및/또는 취소될 수도 있는 선택된 특성들 (113) 을 결정한다. 또한, 결정 모듈 (298) 은 정보 (예를 들어, 아이템 목록들 (85)) 를 결정 또는 발견하고, 그 결정된 선택특성들 (113) 에 기초하여 브라우징 셋트들 (303) 을 결정 또는 발견한다. 마지막으로, 생성 모듈 (300) 은 브라우징 값들 (286) 과 연관될 수도 있는 카운트 값들을 생성할 수도 있다.

검색 메타데이터 (152) 는 전술한 바와 같이, 도메인 (130) 에 의해 구성되는 것으로 나타내어져 있다. 각각의 도메인 (130) 은 다수의 브라우징 셋트들 (303) 을 포함하는 표시 명령들 (302) 의 셋트를 포함한다. 각각의 브라우징 셋트 (303) 는 브라우징 개념 (284) 및 다수의 브라우징 값들 (286) 을 포함한다. 브라우징 셋트 (303) 는 단일 브라우징 값 (286) 을 선택하여 효과적으로 브라우징 특성 (287) (예를 들어, 브라우징 개념 (284) 및 브라우징 값 (286)) 을 선택할 수도 있는 구매자 (119) 에게 제공될 수도 있다. 브라우징 셋트들 (303) 은 대부분의 유저들의 관심에 따라 순서지어질 수도 있다. 예를 들어, 유저는 표시 명령들 (302) 의 최상위에 나타난 브라우징 셋트들 (303) 에 가장 많은 관심을 가지고, 표시 명령들의 최하위에 나타나는 브라우징 셋트들 (303) 에 가장 적은 관심을 가질 수도 있다. 따라서, 선택된 특성들 (113) 에 기초하여 어느 브라우 징 셋트들 (303) 을 유저에게 제공할 지를 결정하고, 단일 디스플레이 상에 모든 브라우징 셋트들 (303) 을 제공하는 능력을 배제하는 디스플레이 상의 한정된 영역을 결정하기 위해, 표시 명령들 (302) 이 결정 모듈 (298) 에 의해 이용될 수도 있다.

도 18 은 일 실시형태에 따른, 분류 엔진 (114) 을 나타낸다. 분류 엔진 (114) 은 전술한 바와 같이, 분류 태그들 (97) 및 추론 태그들 (99) 을 포함하는 아이템 분류 정보 (131) 및 아이템 정보 (120) 를 포함하는 태깅된 아이템 정보 (93) 엔트리들을 포함한다. 결정 모듈 (298) 은 정보 (예를 들어, 아이템 목록들 (85)) (예를 들어, "발견된 아이템들") 를 결정하거나 발견하기 위해, 개념 쿼리 (111) 및, 일부 예에서는, 키워드들 (228) (예를 들어, 임의의 분류 구문 (133) 으로 참으로 평가되지 않을 수도 있는 키워드 쿼리 (109) 에 포함된 키워드들 (228)) 과 연관된 선택된 특성(들) (113) 을 이용한다.

도 19 는 브라우징에서 데이터 아이템을 식별하기 위한 방법의 일 실시형태 (304) 를 나타낸다. 클라이언트 머신 (22) 에서의 동작들은 좌측에 나타나고, 애플리케이션 서버 (28) 에서의 동작들은 우측에 나타난다. 동작 306 에서, 유저는 키워드 쿼리 (109) 를 입력하고, 이는 애플리케이션 서버 (28) 로 전달된다.

동작 308 에서, 애플리케이션 서버 (28) 에서, 검색 애플리케이션들 (57) 은 키워드 쿼리 (109) 를 수신하고, 하나 이상의 선택된 특성들 (113) 을 포함하는 개념 쿼리 (111) 를 생성한다. 예를 들어, 검색 애플리케이션 (57) 은 키워드 쿼리 "검정색 Nike 사이즈 8" 를 수신하고, 3 개의 선택된 특성들 (113) 을 포함하는 도메인 (130) "신발" 에 대한 개념 쿼리 (111) (예를 들어, "컬러 - 검정색", "브랜드 - Nike", 및 "신발 사이즈 - 8") 를 생성한다. 그 다음, 검색 애플리케이션들 (57) 은 개념 쿼리 (111) 와 연관된 선택된 특성들 (113) 에 기초하여 유저 인터페이스를 생성한다.

도 20 은 일 실시형태에 따른, 선택된 특성들 (113) 및 키워드(들) (228) 에 기초하여 유저 인터페이스를 생성하기 위한 방법 (310) 을 나타낸다. 방법 (310) 은 동작 312 에서 시작하고, 여기서 결정 모듈 (298) 은 한 셋트의 정보 (예를 들어, 아이템 목록들 (85)) 를 결정한다.

도 21 은 선택된 특성들 (113) 및 키워드(들) (228) 에 기초하여 아이템 목록들 (85) 의 셋트를 판정하기 위한 방법의 일 실시예 (312) 를 나타내는 블록도이다. 방법 (312) 은 동작 314 에서 시작하고, 여기서, 결정 모듈 (298) 은 도메인 (130) "신발" 과 연관될 수도 있는 분류 엔진 (114) 으로부터 아이템 (예를 들어, 태깅된 아이템 정보 (93)) 를 판독한다.

결정 동작 318 에서, 결정 모듈 (298) 은 표현을 형성하고 그 표현이 참이라고 평가되는지를 판정하기 위해 개념 쿼리 (111) 와 연관된 키워드(들) (228) 및 선택된 특성들 (113) 을 이용한다. 예를 들어, 결정 모듈 (289) 은 분류 태그들 (97) 및/또는 추론 태그들 (93) 을 평가하기 위해 "'컬러 = 검정색' AND '브랜드 = Nike' AND '신발 사이즈 = 8'" 을 이용할 수도 있다. 또한, 결정 모듈은 아이템 정보 (120) 를 평가하기 위해 키워드들 (228) (예를 들어, 임의의 분류 구문 (133) 을 이용하여 참이라고 평가되지 않을 수도 있는 키워드 쿼리 (109) 에 포 함된 키워드들 (228)) 을 이용할 수도 있다. 표현 (예를 들어, 불리언) 이 참이라고 평가하면, 브랜치는 동작 324 로 간다. 그렇지 않으면 브랜치는 결정 동작 322 로 간다.

동작 324 에서, 결정 모듈 (298) 은 발견되는 아이템 (예를 들어, "발견된 아이템") 을 등록한다.

판정 동작 322 에서, 결정 모듈 (298) 은 분류 엔진 (114) 에서 도메인 (130) "신발" 과 연관된 더 많은 아이템들이 존재하는지를 판정한다. 더 많은 아이템들이 존재한다면 브랜치는 동작 314 로 간다. 그렇지 않으면 방법은 종료한다.

도 20 으로 돌아와서, 동작 326 에서, 결정 모듈 (298) 은 선택된 특성들 (113) 에 기초하여 유저에게 표시할 브라우징 셋트들 (303) 을 결정한다. 예를 들어, 결정 모듈 (298) 은 유저 인터페이스 상의 이용가능한 공간을 점유하기에 충분한 가장 관심 있는 브라우징 셋트들 (303) 을 결정하기 위해 적절한 표시 명령들 (302) 을 액세스할 수도 있다.

도 22 는 브라우징 셋트들 (303) 을 결정하기 위한 방법의 일 실시형태 (326) 를 나타낸다. 방법 (326) 은 동작 313 에서 시작하고, 여기서, 결정 모듈 (298) 은 적절한 도메인 (130) 에 기초하여 검색 메타데이터 (152) 로부터 그 다음 브라우징 셋트 (301) 를 판독한다. 예를 들어, 결정 모듈 (298) 은 도메인 (130) "신발" 과 연관될 수도 있는 표시 명령들 (302) 과 연관될 수도 있는 브라우징 셋트 (301) 를 판독할 수도 있다.

동작 315 에서, 결정 모듈 (298) 은 그 다음 선택된 특성 (113) 을 판독한다. 결정 동작 317 에서, 결정 모듈 (298) 은 선택된 특성 (113) 과 연관된 선택된 개념 (115) 을 브라우징 셋트 (301) 와 연관된 브라우징 개념 (284) 과 비교한다. 선택된 개념 (115) 과 브라우징 개념 (284) 이 매칭되면, 결정 모듈 (298) 은 동작 321 로 간다 (예를 들어, 선택된 개념에 대응하는 브라우징 셋트를 표시하지 않음). 그렇지 않으면, 결정 모듈 (298) 은 결정 동작 319 로 간다.

동작 319 에서, 결정 모듈 (298) 은 추가 선택된 특성들 (113) 이 존재하는지를 판정한다. 추가 선택된 특성들 (113) 이 존재한다면, 브랜치는 동작 315 로 간다. 그렇지 않으면, 브랜치는 동작 321 로 간다.

동작 321 에서, 결정 모듈 (298) 은 유저 인터페이스에 표시될 브라우징 셋트 (301) 를 등록한다.

결정 동작 323 에서, 결정 모듈 (298) 은 다른 브라우징 셋트 (303) 가 유저 인터페이스 상에 표시될 수도 있는지를 판정한다. 다른 브라우징 셋트 (303) 가 표시될 수도 있다면, 브랜치는 결정 동작 325 로 간다. 그렇지 않으면, 프로세싱은 종료한다.

결정 동작 325 에서, 결정 모듈 (298) 은 더 많은 브라우징 셋트들 (303) 이 존재하는지를 판정한다. 더 많은 브라우징 셋트들 (303) 이 존재한다면, 브랜치는 동작 313 으로 간다. 그렇지 않으면 프로세싱은 종료한다.

전술한 실시형태는, 표시 명령들 (302) 에서 나타나는 바와 같이 브라우징 셋트들 (301) 의 순서에 기초하여 유저에 대해 제공하기 위한 브라우징 셋트들 (301) 을 선택한다. 따라서, 표시 명령들 (302) 은 유저에 대해 브라우징 셋트들 (301) 의 표시에 대한 관심의 고정 순서를 결정한다. 다른 실시형태에서, 관심의 고정 순서는 선택된 특성 (113) 과 관련하여 선택된 특성 (113) 의 취소에 의해 임시로 번복될 수도 있다. 이 예시에서, 취소된 선택된 특성 (113) 은 유저에 대해 최대 관심으로 임시로 간주될 수도 있고, 따라서, 대응하는 선택된 특성 (113) 의 취소 다음의 유저에 대한 브라우징 셋트 (301) 로서 표시될 수도 있다. 따라서, 관심의 고정 순서는 취소된 선택된 특성 (113) 과 연관될 수도 있는 브라우징 값 (286) 을 취소하기를 원할 수도 있는 유저를 수용하기 위해 임시로 번복될 수도 있다.

도 20 으로 돌아가서, 동작 328 에서, 생성 모듈 (300) 은 유저 인터페이서 상에 표시될 수도 있는 브라우징 셋트들 (303) 과 연관된 브라우징 값들 (286) 의 각각에 대한 카운트를 생성한다.

도 23 은 브라우징 값들 (286) 에 대한 카운트들을 생성하기 위한 방법의 일 실시형태 (328) 를 나타낸다. 동작 330 에서, 생성 모듈 (300) 은 (예를 들어, 동작 324 에 기초하여) 선택된 특성들 (113) 및 키워드(들) (228) 에 기초하여 발견될 수도 있는 그 다음 아이템을 판독한다.

동작 332 에서, 생성 모듈 (300) 은 적절한 표시 명령들 (302) 로부터 그 다음 브라우징 셋트 (303) 를 판독한다. 예를 들어, 적절한 표시 명령들 (302) 은 개념 쿼리 (111) 과 연관된 도메인 (130) 과 매칭되는 도메인 (130) 과 연관될 수도 있다.

동작 333 에서, 생성 모듈 (300) 은 현재 브라우징 셋트 (303) 와 연관된 그 다음 브라우징 값 (286) 을 판독한다.

결정 동작 334 에서, 생성 모듈 (300) 은 현재 브라우징 개념 (284) 및 현재 브라우징 값 (286) (예를 들어, 컬러 = 검정색) 을 포함하는 표현 (예를 들어, 불리언) 을 이용하여 현재 아이템을 평가한다. 표현 (예를 들어, 불리언) 이 참이라고 평가하면, 브랜치는 동작 336 으로 간다. 그렇지 않으면, 브랜치는 결정 동작 337 로 간다.

동작 336 에서, 생성 모듈 (300) 은 적절한 카운터 (예를 들어, 현재 브라우징 개념 (284) (예를 들어, 컬러) 및 현재 브라우징 값 (286) (예를 들어, 검정색) 에 대응하는 카운터) 를 증가시킨다.

동작 337 에서, 생성 모듈 (300) 은 현재 브라우징 셋트 (301) 와 연관된 더 많은 브라우징 값들 (286) 이 존재하는지를 판정한다. 더 많은 브라우징 값들 (286) 이 존재한다면, 브랜치는 동작 333 으로 간다. 그렇지 않으면, 브랜치는 동작 338 로 간다.

결정 동작 338 에서, 생성 모듈 (300) 은 더 많은 브라우징 셋트들 (303) 이 존재하는지를 판정한다. 더 많은 브라우징 셋트들 (303) 이 존재한다면, 브랜치는 동작 332 로 간다. 그렇지 않으면, 브랜치는 결정 동작 340 으로 간다.

결정 동작 (340) 에서, 생성 모듈 (300) 은 (예를 들어, 동작 324 에서 선택된 특성들 (113) 에 기초하여 발견된) 더 많은 발견된 아이템들 이 존재하는지를 판정한다. 더 많은 발견된 아이템들이 존재한다면, 브랜치는 동작 330 으로 간 다. 그렇지 않으면, 프로세싱은 종료한다.

도 19 로 돌아가서, 동작 360 에서, 애플리케이션 서버 (28) 에서, 검색 애플리케이션들 (57) 은 생성된 유저 인터페이스를 클라이언트 머신 (22) 에 전달한다.

동작 362 에서, 클라이언트 머신 (22) 은 유저에 대해 생성된 유저 인터페이스를 표시한다. 도 34 는 일 실시형태에 따른, 생성된 유저 인터페이스 (363) 를 나타낸다. 유저 인터페이스 (363) 는 키워드 쿼리 (109) (예를 들어, "검정색 Nike 사이즈 8"), 도메인 (130) ("신발"), 개념 쿼리 (111) (예를 들어, 컬러 = 검정색, 브랜드 = Nike, 신발 사이즈 = 8), 브라우징 개념들 (284) (예를 들어, "제품 타입", 신발 스타일", "가격 범위"), 브라우징 값들 (286) (예를 들어, "남자 신발", "여자 신발" 등), 브라우징 값들 (286) 의 각각과 연관된 카운트들 (365), 및 선택된 특성들 (113) 에 기초하여 발견될 수도 있는 정보 (예를 들어, 아이템 목록들 (85)) 을 포함한다.

클라이언트 머신 (22) 에서, 유저는 "남자 신발" 을 선택하고, 그에 의해, 브라우징 특성 (287) (예를 들어, "제품 타입 - 남자 신발") 의 선택을 나타낸다. 도 19 로 돌아가서, 동작 364 에서, 클라이언트 머신 (22) 은 그 브라우징 특성 (287) 선택을 애플리케이션 서버 (28) 에 전달한다.

동작 372 에서, 애플리케이션 서버 (28) 에서, 결정 모듈 (298) 은 개념 쿼리 (111) 및 브라우징 특성 (287) 과 연관된 선택된 특성 (113) 을 수신하고, 누적되는 선택된 특성들 (113) 을 결정한다. 예를 들어, 결정 모듈 (298) 은 "컬러 - 검정색", "브랜드 -Nike", "신발 사이즈 - 8", "제품 타입 -남자 신발" 을 포함하는 누적되는 선택된 특성들 (113) 을 결정할 수도 있다. 그 다음, 결정 모듈 (298) 및 생성 모듈 (300) 은 도 20 의 방법 (310) 에서 전술한 바와 같이, 누적되는 선택된 특성들 (113) 및 키워드(들) (228) 을 이용하여 유저 인터페이스를 생성할 수도 있다.

동작 374 에서, 생성된 유저 인터페이스는 클라이언트 머신 (22) 으로 전달된다.

동작 376 에서, 클라이언트 머신 (22) 은 그 생성된 유저 인터페이스를 수신하고 표시한다. 도 35 는 일 실시형태에 따른, 생성된 유저 인터페이스 (378) 를 나타낸다. 유저 인터페이스 (378) 는 추가적인 선택된 특성 (113) "제품 타입 - 남자 신발" 을 나타낸다. 또한, 브라우징 개념 (284) "신발 폭" 과 연관된 브라우징 셋트 (303) 가 유저 인터페이스 (378) 에 부가되고, 그에 의해, 누적되는 선택된 특성들 (113) 에 기초하여 유저에게 가장 관심 있는 브라우징 셋트들 (303) (예를 들어, "신발 폭", "신발 스타일", "가격 범위") 을 제공한다. 각각의 브라우징 셋트 (303) 는 브라우징 셋트 (303) 와 연관될 수도 있는 추가적인 브라우징 값들 (286) 을 제공하기 위해 선택될 수도 있는 "추가 선택" 버튼 (305)과 연관되는 것으로 나타내어져 있다. 또한, 유저 인터페이스 (378) 는 대응하는 이름의 브라우징 셋트들 (303) 을 선택하기 위해 유저에 의해 선택될 수도 있는 다수의 브라우징 셋트 버튼들 (307) (예를 들어, "상태", "신발 세부-스타일", "구매 옵션") 을 포함하는 것으로 나타내어져 있다. 좌측에서 우측으로 판독하는 브라우징 셋트 버튼들 (307) 은 유저에게 그 다음 3 개의 가장 관심 있는 브라우징 셋트들 (303) 을 제공할 수도 있을 것이다.

카운트들 (365) 은 재계산되고, 정보 (예를 들어, 아이템 목록들 (85)) (예를 들어, "발견된 아이템") 는 누적되는 선택된 특성들 (113) 및 키워드(들) (228) 에 기초하여 업데이트된다. 유저 인터페이스 (378) 는 선택된 특성들 (113) 의 각각과 연관되는 "취소" 버튼들 (381) 을 추가로 포함하고, 그에 의해 유저가 나머지 선택된 특성들 (113) 을 제거하지 않고서도 특정 선택된 특성 (113) 을 취소할 수 있도록 한다. 본 실시예에서, 유저는 선택된 특성 (113) "신발 사이즈 - 8" 과 연관된 "취소" 버튼 (381) 을 선택하지만, 유저는 임의의 선택된 특성들 (113) (예를 들어, "컬러 - 검정색", "브랜드 - Nike", "신발 사이즈 8" 또는 "제품 타입 - 남자 신발") 과 연관된 "취소" 버튼 (381) 을 선택할 수도 있고, 나머지 선택된 특성들 (113) 은 정보 (예를 들어, 아이템 목록들) 를 찾고, 표시할 가장 관심 있는 브라우징 셋트들 (301) 을 결정하며, 연관된 브라우징 값들 (286) 에 대한 카운트들을 생성하기 위해 이용될 수도 있다. 도 19 로 돌아가서, 동작 390 에서, 클라이언트 머신 (22) 은 개념 쿼리 (111), 선택된 브라우징 특성 (287) (예를 들어, "제품 타입 - 남자 신발") 및 취소된 선택된 특성 (예를 들어, "신발 사이즈 - 8") 을 애플리케이션 서버 (28) 에 전달한다.

동작 392 에서, 애플리케이션 서버 (28) 에서, 결정 모듈 (298) 은 개념 쿼리 (111), 선택된 브라우징 특성 (287) (예를 들어, "제품 타입 - 남자 신발") 및 취소된 선택된 특성 (예를 들어, "신발 사이즈 - 8") 을 수신하고, 누적되는 선택 된 특성들 (113) 을 판정한다. 예를 들어, 결정 모듈 (298) 은 "컬러 - 검정색", "브랜드 - Nike", "제품 타입 - 남자 신발" 을 포함하는 누적되는 선택된 특성들 (113) 을 결정할 수도 있다. 그 다음, 결정 모듈 (298) 및 생성 모듈 (300) 은 도 20 의 방법 (310) 에서 전술한 바와 같이, 누적되는 선택된 특성들 (113) 을 이용하여 유저 인터페이스를 생성한다.

동작 394 에서, 생성된 유저 인터페이스는 클라이언트 머신 (22) 으로 전달된다.

동작 396 에서, 클라이언트 머신 (22) 은 생성된 유저 인터페이스를 수신하고 표시한다. 도 36 은 일 실시형태에 따른, 생성된 유저 인터페이스 (398) 를 나타낸다. 유저 인터페이스 (398) 는 더 이상 취소된 선택된 특성들 (113) "신발 사이즈-8" 을 포함하지 않는 것으로 나타내어져 있다. 또한, 브라우징 개념 (284) "신발 폭" 과 연관되었던 브라우징 셋트 (303) 는 브라우징 개념과 연관된 브라우징 셋트 (303) 에 의해 대체될 수도 있다 (예를 들어, 그에 의해 누적되는 선택된 특성들 (113) 에 따라 가장 관심 있는 브라우징 셋트들 (303) 을 유저에게 제공한다. 마지막으로, 카운트들 (365) 은 재계산되고, 정보 (예를 들어, 아이템 목록들 (85)) (예를 들어, "발견된 아이템들") 는 업데이트된 선택된 특성들 (113) ("컬러 - 검정색", "브랜드 -Nike", "제품 타입 - 남자 신발") 에 기초하여 업데이트될 수도 있다. 다른 실시형태에서, 브라우징 옵션들 (예를 들어, 브라우징 셋트들 (301) 및 브라우징 셋트 버튼들 (307)) 은 추가적인 정보 (예를 들어, 아이템 목록들 (85)) 를 표시하기 위해 최소화될 수도 있다.

동적 표시

도 37 은 브라우징 옵션들의 표시를 최소화하기 위한 유저 인터페이스의 일 실시형태 (400) 를 나타낸다. 유저 인터페이스 (400) 는 아이템 카운트의 임계 레벨 아래로의 드롭에 기초하여 브라우징 옵션들의 표시를 최소화하고, 정보 (예를 들어, 아이템 목록들 (85)) 의 표시를 최대화한다. 예를 들어, 유저 인터페이스 (400) 는 472 에서 발견된 아이템들의 "20" 카운트를 포함할 수도 있고, 이 카운트는 결정 모듈 (298) 에 의해 구성가능한 임계값 아래라고 판정되고, 결과적으로 유저 인터페이스 (400) 상의 브라우징 옵션들의 최소화를 가져온다. 이를 위해, 브라우징 셋트 버튼들 (307) (예를 들어, "상태", "신발 세부-스타일", "구매 옵션들") 이 유저 인터페이스 (400) 상에서 계속 표시될 수 있음에도 불구하고, 브라우징 셋트들 (301) 은 유저 인터페이스 (400) 에 표시되지 않을 수도 있다. 브라우징 셋트들 (301) 대신에 추가적인 정보 (예를 들어, 아이템 목록들 (85) 이 표시될 수도 있다. 따라서, 임계값 아래로 떨어지는 아이템 목록들 (85) 의 카운트는 브라우징 옵션들보다는 발견된 정보 (예를 들어, 아이템 목록들 (85)) 를 강조하는 유저 인터페이스의 생성을 트리거할 수도 있다.

키워드 쿼리를 수신하고, 키워드 쿼리, 개념 쿼리, 브라우징 특성들 및 저오 (예를 들어, 아이템 목록들 (85)) 을 포함하는 유저 인터페이스를 생선하는 시스템의 다른 실시형태는 단일 불리언 평가 그래프를 포함할 수도 있다. 불리언 평가 그래프는 불리언 평가들의 성능을 향상시키기 위해 시스템에 의해 이용될 수도 있다. 예를 들어, 시스템은 불리언 평가 그래프를 이용하여 시스템에 의해 계 산되는 평가 이벤트들의 총 수는 최소화하면서, 정보 (예를 들어, 아이템 정보 (85)) 에 대한 큰 셋트의 선택된 특성들 (113) 및 키워드들 (228) 을 평가할 수도 있다. 또 다른 실시형태에서, 시스템은 정보 (예를 들어, 아이템 목록들 (85)) 에 대한 큰 셋트의 브라우징 특성들 (287) 을 평가하기 위해 불리언 평가 그래프를 이용할 수도 있다.

프로세싱 백 버튼 선택

도 24 는 일 실시형태에 따른, 유저 인터페이스 (401) 및 브라우저 제어들 (403) 을 나타내는 블록도이다. 유저 인터페이스들 (401) 은 클라이언트 머신에서 표시될 수도 있고, 유저 인터페이스 (407), 유저 인터페이스 (409), 및 유저 인터페이스 (411) 을 포함한다. 유저 인터페이스 (409) 는 클라이언트 머신에서 실행되어 유저 인터페이스 (409 및 411) 를 생성하고 표시할 수도 있는 클라이언트 애플리케이션 프로그램 (예를 들어, 애플릿, JavaScript 등) 을 포함할 수도 있다. 브라우저 제어들 (403) 은 유저에 의해 선택되어 브라우저가 이전 유저 인터페이스를 유저에게 표시하도록 트리거하는 백 버튼 (405) 을 포함한다.

유저 인터페이스 (401) 는 클라이언트 애플리케이션과 브라우저 사이의 간섭으로 인한 문제를 나타낸다. 예를 들어, 클라이언트 머신의 유저는 유저 인터페이스 (407) 로부터 버튼 (415) (예를 들어, "A") 을 선택할 수도 있고, 그에 의해 클라이언트 머신의 브라우저가 서버로부터 유저 인터페이스 (409) 를 요청하도록 트리거할 수도 있다. 이에 응답하여, 서버는 클라이언트 애플리케이션 프로그램 (예를 들어, JavaScript) 을 포함하는, 유저 인터페이스 (409) 를 클라이언트 머신으로 전달하고, 클라이언트 머신에서 클라이언트 애플리케이션 프로그램이 실행되어 유저 인터페이스 (409) 를 유저에 대해 표시한다. 그 다음, 클라이언트 머신에서 유저는 유저 인터페이스 (409) 로부터 버튼 (415) (예를 들어, "B") 를 선택할 수도 있고, 이는 클라이언트 머신에서 클라이언트 애플리케이션 프로그램에 의해 처리되어 유저 인터페이스 (411) 를 생성하고 표시할 수도 있다. 유저가 이제 백 버튼 (405) 을 선택하면, 브라우저는 서버에 액세스하여 응답하여 유저에 의해 희망되듯이, 유저 인터페이스 (409) 대신에 유저 인터페이스 (407) 를 복구하고 표시할 수도 있다. JavaScript 가 유저 인터페이스 (411) 를 이용하여 디스플레이를 업데이트하기 위해 실행되었다는 것을 알지 못하고 브라우저가 동작하기 때문에, 브라우저는 이러한 방식으로 응답한다.

도 25 는 브라우저 백 버튼을 처리하기 위한, 일 실시형태에 따른, 시스템 (420) 을 나타내는 블록도이다. 시스템 (420) 은 전술한 바와 같이, 클라이언트 머신 (22) 과 네트워크 (14) 를 통해 통신하는 서버 머신 또는 애플리케이션 서버 (28) 를 포함하는 네트워크 기반 컴퓨터-기반 시스템 (12) 을 포함한다. 클라이언트 머신 (22) 은 프로그램적 클라이언트 (18) (예를 들어, 브라우저), 감추어진 프레임 (432), 감추어진 유저 인터페이스 (425, 427, 429), 시각적 프레임 (430), 및 클라이언트 애플리케이션 프로그램 (428) (예를 들어, 스크립트, 프로그램, 애플릿 등) 및 유저 인터페이스 엘리먼트들 (418) 을 포함하는 시각적 유저 인터페이스 (426) 를 포함하는 것으로 나타내어져 있다. 프로그램적 클라이언트 (18) (예를 들어, 브라우저) 는 애플리케이션 서버 (28) 로부터 시각적 유저 인터 페이스 (426) 및 감추어진 유저 인터페이스들 (425, 427, 429) 을 요청하기 위해 이용될 수도 있다. 또한, 클라이언트 애플리케이션 서버 (28) 는 프로그램적 클라이언트 (18) 에 의해 실행되어 클라이언트 머신 (22) 에서 시각적 프레임 (430) 에서의 표시를 위한 추가적인 유저 인터페이스들 (미도시) 을 생성할 수도 있다. 이를 위해,시각적 및 감추어진 프레임들 (430, 432) 이 프로그램적 클라이언트 (18) 및 클라이언트 애플리케이션 프로그램 (428) 에 의해 이용되는 데이터 구조들과 각각 연관된다.

프레임은 디스플레이의 특정 면적을 분할하는데 이용될 수도 있는 브라우저 구조이다. 본 실시예에서, 감추어진 프레임 (432) 은 표시 영역으로 분할되지 않는다. 따라서, 프로그램적 클라이언트 (18) 는 애플리케이션 서버 (28) 로부터 감추어진 유저 인터페이스들 (425, 427, 429) 를 요청할 수도 있지만, 감추어진 유저 인터페이스 (425, 427, 429) 의 표시는 유저에 대해 시각적인 유저 인터페이스 엘리먼트들을 생성하지 못한다. 본 응용에서, 감추어진 유저 인터페이스들 (425, 427, 429) 은 백 버튼 (405) 의 적절한 처리를 가능하게 하기 위해서만 이용된다. 또한, 감추어진 유저 인터페이스들 (425, 427, 429) 은 정적으로 식별되고, 그에 의해, 그 프로그램적 클라이언트 (18) 가 그 감추어진 유저 인터페이스들 (425, 427, 429) 을 클라이언트 머신 (22) 의 캐시 (미도시) 에 저장하도록 트리거링한다.

컴퓨터-기반 시스템 (12) 은 수신 모듈 (422) 및 통신모듈 (424) 을 포함하는 검색 애플리케이션들 (57) 을 포함하는 애플리케이션 서버 (28) 를 포함하는 것 으로 나타내어져 있다. 수신 모듈 (422) 은 시각적 유저 인터페이스 (426) 및 감추어진 유저 인터페이스들 (425, 427, 429) 에 대한 요청들을 수신하고, 요청된 유저 인터페이스들 (426, 427, 429) 을 생성하거나, 데이터베이스 (36) 로부터 그 요청된 유저 인터페이스 (426, 425, 427, 429) 를 판독한다. 통신 모듈 (424) 은 이 시각적 또는 감추어진 유저 인터페이스들 (426, 425, 427, 429) 을 클라이언트 머신 (22) 에 전달한다.

도 26 은 일 실시형태에 따른, 클라이언트 머신 (22) 과 연관된 소프트웨어 컴포넌트들을 추가로 나타내는 블록도이다. 클라이언트 머신 (22) 은 프로그램적 클라이언트 (18) (예를 들어, 브라우저), 캐시 (434), 유저 인터페이스 내력 (436), 시각적 프레임 (430) 및 감추어진 프레임 (432) 을 포함하는 것으로 나타내어져 있다.

캐시 (434) 는, 정적인 유저 인터페이스에 대한 요청과 표시의 업데이트 사이의 지연을 최소화할 목적으로 정적 유저 인터페이스 (예를 들어, 감추어진 유저 인터페이스 (425, 427, 429) 를 저장하고 복구하기 위해 프로그램적 클라이언트 (18) 에 의해 이용될 수도 있다. 따라서, 캐시 (434) 는 애플리케이션 서버 (28) 대신 정적인 유저 인터페이스를 복구하는데 이용될 수도 있다.

유저 인터페이스 내력 (436) 은, 각각의 시각적 및 감추어진 프레임들 (430, 432) 에서 표시될 유저 인터페이스들을 기록하기 위해, 프로그램적 클라이언트 (18) 에 의해 저장될 수도 있는 프레임 (438) 및 URL (431) 을 포함한다. 예를 들어, 일 실시형태에서, 유저 인터페이스 내력 (436) 은 스택과 같이 동작할 수도 있고, 이에 의해, 프로그램적 클라이언트 (18) 는, (예를 들어, URL (431) 에 대응하는) 유저 인터페이스가 프레임 (438) (예를 들어, 시각적 프레임 (430), 감추어진 프레임 (432) 등) 에 표시되도록 유저가 요청하는 것에 응답하여, 프레임 (438) 및 URL (431) 쌍을 스택 상으로 푸시할 수도 있다. 프로그램적 클라이언트 (18) 는 유저가 백 버튼을 선택하는 것에 응답하여 하나 이상의 프레임 (438) 및 URL (431) 쌍들을 스택으로부터 팝핑할 수도 있고, 프로그램적 클라이언트 (18) 는 지정된 프레임에 이전 유저 인터페이스를 재표시한다. 따라서, 유저 인터페이스 내력 (436) 은 제일 먼저 입력 제일 나중 출력 버퍼 (first-in last-out buffer) 으로서 동작할 수도 있고, 이에 의해, 유저에 의해 선택된 유저 인터페이스들의 순서를 보전하는 메커니즘을 제공하고, 반복적으로 백 버튼 (405) 을 선택하는 유저에 응답하여 역방향 순서의 유저 인터페이스를 유저가 리뷰할 수 있도록 한다.

시각적 프레임 (430) 및 감추어진 프레임 (432) 은 프로그램적 클라이언트 시각적 및 감추어진 상태들 (435, 437), 시각적 및 감추어진 프레임 객체들 (443, 445), 클라이언트 애플리케이션 프로그램 시각적 및 감추어진 프레임 상태들 (439, 441), 시각적 유저 인터페이스들 (426, 466, 492) 및 감추어진 유저 인터페이스들 (425, 427, 429) 을 포함한다.

프로그램적 클라이언트 시각적 및 감추어진 프레임 상태들 (435, 437) 은 각각 URL (447, 449) 을 포함한다. 프로그램적 클라이언트 (18) 는, 클라이언트 애플리케이션 프로그램 (428) 이 프로그램적 클라이언트 (18) 에 대해, 애플리케이 션 서버 (28) 로부터의 유저 인터페이스가 각각의 프레임 (430, 432) 에 표시되도록 요청하도록 요청하였는지를 판정하기 위해 시각적 및 감추어진 프레임 상태들 (435, 437) 을 이용할 수도 있다.

시각적 및 감추어진 프레임 객체들 (443, 445) 각각은 URL 들 (451, 453) 을포함하고, 이는 프로그램적 클라이언트 (18) 및 클라이언트 애플리케이션 프로그램 (428) 에 의해 모니터링되고 업데이트될 수도 있다. URL 들 (451, 453) 은 각각의 시각적 프레임들 (430) 및 감추어진 프레임들 (432) 에 표시되는 요청된 또는 실제의 유저 인터페이스를 나타낸다.

클라이언트 애플리케이션 프로그램 시각적 및 감추어진 프레임 상태들 (439, 441) 각각은 URL 들 (455, 467) 을 포함한다. 클라이언트 애플리케이션 프로그램 (428) 은, 프로그램적 클라이언트 (18) 가 각각의 시각적 프레임 (430) 또는 감추어진 프레임 (432) 과 연관된 유저 인터페이스를 업데이트하였는지를 판정하기 위해 시각적 및 감추어진 프레임 상태들 (439, 441) 을 이용할 수도 있다.

시각적 유저 인터페이스들은 시각적 유저 인터페이스 (426), 모드 = Default, 시각적 유저 인터페이스 (466), 모드 = More, 및 시각적 유저 인터페이스 (492), 모드 = All 를 포함한다. 감추어진 유저 인터페이스들은 감추어진 유저 인터페이스 (425), 모드 = Default, 감추어진 유저 인터페이스 (427), 모드 = More, 및 감추어진 유저 인터페이스 (429), 모드 = All 를 포함한다.

시각적 유저 인터페이스 (426) 는 전술한 바와 같이, 클라이언트 애플리케이션 프로그램 (428) 및 유저 인터페이스 엘리먼트들 (448) 을 포함한다. 유저 인터페이스 엘리먼트들 (448) 은 그래픽, 텍스트, 또는 문자 숫자식 스트링들을 포함할 수도 있고, 이는 클라이언트 머신 (22) 상에 표시될 수도 있고, 이것이 유저에 의해 선택될 때, 클라이언트 애플리케이션 프로그램 (428) 에 대한 이벤트의 전달을 가져올 수도 있다. 예를 들어, 클라이언트 애플리케이션 프로그램 (428) 은, 유저가 "MORE" 또는 "ALL" 유저 인터페이스 엘리먼트 (448) 를 선택함에 각각 응답하여 시각적 유저 인터페이스 (466 또는 492) 의 생성 및 표시를 트리거하는 이벤트를 수신할 수도 있다.

프로그램 클라이언트 (18) 는 각각의 시각적 및 감추어진 프레임 객체들 (443, 445) 과 연관된 백 버튼 (405) 및 URL 들 (451, 453) 을 모니터링한다. 프로그램적 클라이언트 (18) 는 백 버튼 (405) 의 선택 또는 URL (451, 453) 에서의 변화에 응답할 수도 있다. 프로그램적 클라이언트 (18) 는 캐시 (434) 또는 애플리케이션 서버 (28) 로부터 요청된 유저 인터페이스를 복구하기 위해 유저 인터페이스 내력 (436) 을 잉요하여 백 버튼 (405) 의 선택에 응답할 수도 있다. 프로그램적 클라이언트 (18) 는 시각적 유저 인터페이스 (492), 모드 = Default 를 포함하는 URL (451) 에 의해 식별되는 유저 인터페이스를 복구함으로써 URL (451) 의 변화에 응답할 수도 있다. 프로그램적 클라이언트 (18) 는 감추어진 유저 인터페이스 (425), 모드 = Default 또는 감추어진 유저 인터페이스 (427), 모드 = More 또는 감추어진 유저 인터페이스 (429), 모드 = All 을 포함하는 URL (453) 에 의해 식별되는 감추어진 유저 인터페이스를 수신하여 URL (453) 에서의 변화에 응답할 수도 있다.

클라이언트 애플리케이션 프로그램 (428) 은 유저가 유저 인터페이스 엘리먼트들 (448) 을 선택하는 것에 응답하고, 각각의 시각적 및 감추어진 프레임 객체들 (443, 445) 과 연관된 URL 들 (441, 453) 을 모니터링한다. 클라이언트 애플리케이션 프로그램 (428) 은 시각적 프레임 (430) 에 시각적 유저 인터페이스 (426), 모드 = Default, 또는 시각적 유저 인터페이스 (466), 모드 = More, 또는 시각적 유저 인터페이스 (492), 모드 = All 을 생성하고 표시함으로써, 감추어진 프레임 객체 (445) 에서 대응하는 URL (453) 을 업데이트하여 프로그램적 클라이언트가 대응하는 요청된 감추어진 유저 인터페이스 (425, 427, 또는 429) 를 복구하도록 트리거함으로써, 유저 인터페이스 엘리먼트 (448) 의 선택에 응답할 수도 있다.

도 27 은 클라이언트 머신 (22) 에서 백 버튼을 처리하기 위한, 일 실시형태에 따른, 방법 (450) 을 나타내는 상호작용 플로우차트이다. 우측에는 프로그램적 클라이언트 (18) 에 수행되는 동작들이 나타내어져 있고, 좌측에는 클라이언트 애플리케이션 프로그램 (428) 에 의해 수행되는 동작이 나타내어져 있다. 방법 450 은 동작 452 에서 시작하고, 클라이언트 머신 (22) 에서 프로그램적 클라이언트 (18) (예를 들어, 브라우저) 는 대응하는 시각적 유저 인터페이스 (426) 에 대해 요청을 애플리케이션 서버 (28) 에 전달함으로써 유저의 키워드 쿼리 입력에 응답한다. 예를 들어, 키워드들 없는 요청은 다음과 같은 URL 을 포함할 수도 있다.

http://search/VisibleUserInterface?Mode=DEFAULT

도 28 은 유저 인터페이스를 요청하기 위한, 일 실시형태에 따른, 방법 (452) 을 나타내는 상호작용 플로차트이다. 우측에는 애플리케이션 서버 (28) 에서 수행되는 동작들이 나타내어져 있고, 좌측에는 클라이언트 머신 (22) 에서 수행되는 동작들이 나타내어져 있다. 방법 (452) 는 동작 457 에서 시작하고, 클라이언트 머신 (22) 에서, 프로그램적 클라이언트 (18) 는 요청된 URL (431) 및 연관된 프레임 (438) 을 저장함으로써 유저 인터페이스 내력 (436) 의 최상위로 엔트리를 푸시한다. 본 실시예에서, 프로그램적 클라이언트 (18) 는 전술한 URL 및 시각적 프레임 (430) 을 저장한다.

결정 동작 (459) 에서, 프로그램적 클라이언트 (18) 는 (예를 들어, URL 에 대응하는) 요청된 유저 인터페이스가 캐시 (434) 에 제공될 수도 있는지를 판정한다. 유저 인터페이스가 캐시 (434) 에 제공된다면, 브랜치는 동작 460 으로 간다. 그렇지 않으면, 브랜치는 동작 461 로 간다.

동작 461 에서,프로그램적 클라이언트 (18) 는 유저 인터페이스에 대한 요청을 애플리케이션 서버 (28) 에 전달할 수도 있다.

동작 463 에서, 애플리케이션 서버 (28) 에서, 수신 모듈 (422) 은 요청을 수신하고, 요청된 유저 인터페이스를 생성하거나, 데이터베이스 (36) 로부터 요청된 유저 인터페이스를 판독하다.

동작 467 에서, 통신 모듈 (424) 은 요청된 유저 인터페이스를 클라이언트 머신 (22) 에 전달하고, 여기서, 요청된 유저 인터페이스는 동작 469 에서 캐시 (434) 에 저장될 수도 있다.

동작 471 에서, 프로그램적 클라이언트 (18) 는 (예를 들어, 감추어진 또는 시각적인) 적절한 프레임에 유저 인터페이스 엘리먼트들을 표시하고 방법 (452) 은 종료한다. 본 실시예에서, 프로그램적 클라이언트 (18) 는 클라이언트 머신 (22) 에서 시각적 유저 인터페이스 (426) 와 연관된 유저 인터페이스 엘리먼트들 (448) 을 표시한다. 도 38 은 일 실시형태에 따른, 시각적 유저 인터페이스 (426) 및 브라우저 제어들 (403) 을 나타낸다. 브라우저 제어들 (403) 은 이전 유저 인터페이스로 돌아가기 위해 유저에 의해 선택될 수도 있는 백 버튼 (405) 을 포함한다. 시각적 유저 인터페이스 (426) 는 전술한 바와 같이, 개념 쿼리 (111), 브라우징 셋트들 (303), 및 정보 (예를 들어, 아이템 목록들 (85)) 를 포함하는 발견된 아이템 (472) 을 포함한다. 또한, 각각의 브라우징 셋트 (303) 는 브라우징 값들 (286) 을 포함하고, 이들의 각각은 전술한 바와 같은 카운트 및 MORE 버튼 (470) (예를 들어, "MORE") 과 연관될 수도 있다. 발견 아이템들 (472) 의 검색을 더 좁히기 위해 브라우징 값들 (286) 이 선택될 수도 있다. 예를 들어, 가격 범위 $30.00-$40.00 의 선택은 그 선택된 가격 범위 (가격 - $30.00-$40.00) 에서 개념 쿼리 (예를 들어, 컬러 - 검정색, 브랜드 -Nike, 사이즈 - 8) 와 매칭되는 아이템들을 찾는 결과를 가져올 수도 있다. 특정 브라우징 셋트 (303) (예를 들어, 발끝 타입, 신발 스타일, 가격 범위) 와 관련하여 추가적인 브라우징 값들 (286) 을 표시하기 위해 유저에 의해 MORE 버튼 (470) 이 선택될 수도 있다.

도 27 로 돌아가서, 클라이언트 머신 (22) 에서, 동작 454 에서, 프로그램적 클라이언트 (18) 는 클라이언트 애플리케이션 프로그램 (428) (예를 들어, 스크립 트) 에 호출한다.

동작 474 에서, 클라이언트 애플리케이션 프로그램 (428) 은 요청을 프로그램적 클라이언트 (18) 에 전달하여 감추어진 유저 인터페이스 (425) 를 요청한다. 예를 들어, 요청은 다음과 같은 URL 을 포함할 수도 있다.

http://search/HiddenUserInterface/static?Mode=DEFAULT

그 다음, 클라이언트 애플리케이션 프로그램 (428) 은 전술한 URL 을 클라이언트 애플리케이션 프로그램 시각적 프레임 상태 (439) 의 URL (455) 에 저장한다.

동작 476 에서, 프로그램적 클라이언트 (18) 는 전술한 URL 을 애플리케이션 서버 (28) 에 전달함으로써 감추어진 유저 인터페이스 (425) 를 요청한다. 예를 들어, 방법 (452) 이 전술한 바와 같이 이용될 수도 있다. 따라서, 감추어진 유저 인터페이스 (425) 의 복구 후, 시각적 및 감추어진 프레인 상태들 (435, 437), 시각적 및 감추어진 프레임 객체들 (443, 445), 및 시각적 및 감추어진 프레임 상태들 (439, 441) 각각은 "DEFAULT" 모드를 지정하는 URL 을 포함한다.

동작 460 에서, 클라이언트 애플리케이션 프로그램 (428) 및 프로그램적 클라이언트 (18) 는 각각의 시각적 및 감추어진 프레임 객체들 (443, 445) 과 연과뇐 URL (451, 453) 을 모니터링 하지만, 모니터링은 클라이언트 머신 (22) 에서 유저의 선택들에 의해 선취될 수도 있다.

도 29(a) 는 "MORE" 유저 인터페이스 엘리먼트 (448) 의 유저 선택을 처리하기 위한, 일 실시형태에 따른, 방법 (490) 을 나타낸다. 방법 (490) 은 동작 465 에서 시작하고, 클라이언트 머신 (22) 에서, 유저는 유저 인터페이스 (426) 상 의 "가격 범위" 브라우징 셋트 (303) 와 연관된 "MORE" 버튼 (470) 을 선택한다. 이에 응답하여, 클라이언트 애플리케이션 프로그램 (428) 은 시각적 유저 인터페이스 (466) (예를 들어, 모드 = MORE) 를 생성하고 표시한다. 클라이언트 애플리케이션 프로그램 (428) 은 애플리케이션 서버 (28) 또는 캐시 (434) 에 액세스하지 않고도 시각적 유저 인터페이스 (466) 를 생성하고 표시한다.

도 39 는 일 실시형태에 따른, 시각적 유저 인터페이스 (466) 및 브라우저 제어들 (403) 을 나타낸다. 브라우저 제어들 (403) 은 백 버튼 (405) 을 포함한다. 시각적 유저 인터페이스 (466) 는 개념 쿼리 (111), 추가적인 (예를 들어, "MORE") 브라우징 값들 (286) 을 포함하는 "가격 범위" 와 연관된 단일 브라우징 셋트 (303) 및 정보 (예를 들어, 아이템 목록들 (85)) 을 포함하는 발견된 아이템 (472) 을 포함한다. 각각의 브라우징 값 (286) 은 체크 박스 (468) 및 카운트오 연관될 수도 있다. 유저는 하나 이상의 체크 박스들을 선택할 수도 있고, 그에 의해 정보 (예를 들어, 아이템 목록들 (85)) 에 대한 검색을 더 좁힐 수 있다. 예를 들어, 유저는 가격 범위 $5.00-$10.00 와 연관된 체크 박스 (468) 및 각겨 범위 $35.00-$40.00 와 연관된 체크 박스 (468) 를 선택할 수도 있다. 따라서, 정보 (예를 들어, 아이템 목록들 (85)) 에 대한 검색은 다음과 같은 검색 기준 "컬러 = 검정색" AND "브랜드 = Nike" AND "사이즈 - 8" AND ((가격 범위 = $5.00-$10.00) OR (가격 범위 = $35.00-$40.00)) 을 포함할 수도 있다.

도 29(a) 로 돌아가서, 동작 474 에서, 클리이언트 애플리케이션 프로그램 (428) 은 감추어진 프레임 객체 (445) 와 연관된 URL (446) 및 클라이언트 애플리 케이션 프로그램 감추어진 프레임 상태 (441) 와 연관된 URL (467) 을 업데이트한다. 예를 들어, 클라이언트 애플리케이션 프로그램 (428) 은 다음과 같은 URL 을 저장할 수도 있다.

http://search/HiddenUserInterface/static?Mode=MORE

도 27 로 돌아가서, 클라이언트 머신 (22) 에서, 결정 동작 (477) 에서, 프로그램적 클라이언트 (18) 는 감추어진 프레임 (432) 순방향 변화가 존재하는지를 판정한다. 예를 들어, 프로그램적 클라이언트 (18) 는 프로그램적 클라이언트 감추어진 프레임 상태 (437) 와 연관된 URL (449) 을 감추어진 프레임 객체 (445) 와 연관된 URL (453) 아 비교하여, 클라이언트 애플리케이션 프로그램 (428) 이 감추어진 프레임 (432) 의 순방향 변화를 요구할 수도 있는지를 판정한다. URL (449) 이URL (453) 과 상이하다면, 클라이언트 애플리케이션 프로그램 (428) 은 감추어진프레임 (432) 과 연관된 유저 인터페이스의 순방향 변화가 요청될 수도 있고, 브랜치는 동작 478 로 간다. 그렇지 않으면, 브랜치는 결정 동작 480 으로 간다.

동작 478 에서, 프로그램적 클라이언트 (18) 는 감추어진 프레임 객체 (445) 와 연관된 URL (453) 로 식별되는 유저 인터페이스를 요청한다. 예를 들어, 프로그램적 클라이언트는 도 28 에 관해 전술한 바와 같이, 방법 (452) 을 이용할 수도 있다. 따라서, 감추어진 프레임 (432) 은 표시가능한 유저 인터페이스 엘리먼트들을 포함하지 않기 때문에, 유저는 클라이언트 머신 (22) 에서 디스플레이 대해 어떤 변화도 감지하지 않는다.

도 29(b) 는 "All" 유저 인터페이스 엘리먼트 (448) 을 처리하기 위한, 일 실시형태에 따른, 방법 (491) 을 나타낸다. 방법 (491) 은 동작 480 에서 시작하고, 클라이언트 머신 (22) 에서, 유저는 시각적 유저 인터페이스 (466) 상에서 "ALL" 버튼 (473) 을 선택한다. 이에 응답하여, 클라이언트 애플리케이션 프로그램 (428) 은 애플리케이션 서버 (28) 또는 캐시 (434) 에 액세스할 필요 없이 시각적 유저 인터페이스 (492) 를 생성하고 표시한다.

도 40 은 일 실시형태에 따른, 가시적 유저 인터페이스 (492) 및 브라우저 제어들 (403) 을 나타낸다. 브라우저 제어들 (403) 은 백 버튼 (405) 을 포함한다. 시각적 유저 인터페이스 (492) 는 개념 쿼리 (111), "가격 범위" 와 연관된 브라우징 셋트 (303) 및 발견 아이템 (472) 을 포함한다. 브라우징 셋트 (303) 는 "가격 범위" 와 연관된 "ALL" 브라우징 값들 (286)을 포함한다. 각각의 브라우징 값 (286) 은 체크 박스 (468) 및 카운트와 연관될 수도 있다. 유저는 하나 이상의 체크 박스들 (468) 을 선택할 수도 있고, 그에 의해, 발견 아이템 (472) 에 대한 검색을 더 협소하게 만들 수도 있다.

도 29(b) 로 돌아가서, 동작 484 에서, 클라이언트 애플리케이션 프로그램 (428) 은 감추어진 프레임 객체 (445) 와 연관된 URL (453) 및 클라이언트 애플리케이션 프로그램 감추어진 프레임 상태 (441) 와 연관된 URL (467) 을 업데이트하고, 절차는 종료한다. 예를 들어, 클라이언트 애플리케이션 프로그램 (428) 은 다음과 같은 URL 을 저장할 수도 있다.

http://search/HiddenUserInterface/static?Mode=ALL

도 27 로 돌아가서, 클라이언트 머신 (22) 에서, 동작 477 에서, 프로그램적 클라이언트 (18) 는 전술한 바와 같이 감추어진 프레임 객체 (445) 와 연관된 URL (453) 의 순방향 변화가 있었는지를 판정한다. 프로그램적 클라이언트 (18) 는 URL (453) 의 순방향 변화가 있었다고 판정하면, 브랜치는 동작 478 로 간다. 그렇지 않으면, 브랜치는 결정 동작 (481) 으로 간다.

동작 478 에서, 프로그램적 클라이언트 (18) 는 감추어진 프레임 객체 (445) 와 연관된 URL (453) 에 저장된 URL 에 기초하여 감추어진 유저 인터페이스 (229) 를 요청한다. 예를 들어, 프로그램적 클라이언트 (18) 는 도 28 에 관해 전술한 바와 같이 방법 (452) 을 이용할 수도 있다.

도 29(c) 는 백 버튼 (405) 의 유저 선택을 처리하기 위한, 일 실시형태에 따른, 방법 (462) 을 나타낸다. 방법 (462) 은 동작 486 에서 시작하고, 클라이언트 머신 (22) 에서, 유저는 브라우저 제어 (403) 로부터 백 버튼 (470) 을 선택한다. 이에 응답하여, 프로그램적 클라이언트 (18) 는 유저 인터페이스 내력 (436) 으로부터 상부 2 개의 엔트리들을 팝핑할 수도 있고, 제 2 엔트리는 프로그램 클라이언트 (18) 에 의해 표시되는 이전의 유저 인터페이스의 URL (431) 및 프레임 (438) 을 포함한다. 예를 들어, 프로그램적 클라이언트 (18) 는 감추어진 프레임 (432) 에 표시되는 이전 유저 인터페이스가 다음 RUL 로 식별될 수도 있는지를 판정할 수도 있다.

http://search/HiddenUserInterface/static?Mode=MORE

동작 488 에서, 프로그램적 클라이언트 (18) 는 전술한 바와 같이 URL 에 의 해 식별되는 유저 인터페이스 (427) 를 요구한다. 예를 들어, 방법 (452) 은 전술한 바와 같이, 유저 인터페이스 (427) 를 요청하기 위해 이용될 수도 있다.

도 27 로 돌아가서, 클라이언트 머신 (22) 에서, 결정 동작 (481) 에서, 클라이언트 애플리케이션 프로그램 (428) 은 감추어진 프레임 객체 (445) 와 연관된 URL (453) 의 후방향 변화가 있었는지를 판정한다. 예를 들어, 클라이언트 애플리케이션 프로그램 (428) 은 (예를 들어, 클라이언트 애플리케이션 프로그램 감추어진 프레임 상태 (441) 와 연관된) URL (467) 을 (예를 들어, 감추어진 프레임 객체 (445) 와 연관된) URL (453) 과 비교하고, 클라이언트 애플리케이션 프로그램 (428) 이 감추어진 프레임 (432) 과 연관된 백 버튼 (405) 요청을 처리하였는지를 판정한다. URL (467) 이 URL (453) 과 상이하다면, 브랜치는 동작 483 으로 간다. 그렇지 않으면, 브랜치는 결정 동작 (477) 으로 간다.

동작 483 에서, 프로그램적 클라이언트 (18) 는 URL (453) 에 의해 식별되는 유저 인터페이스 엘리먼트들 (448) 에 기초하여 가시적인 프레임 (430) 을 업데이트한다. 예를 들어, 다음 URL (453) 은 프로그램적 클라이언트 (18) 에 대해, "MORE" 모드에 대응하는 가시적 유저 인터페이스 (466) 를 갖는 가시적인 프레임 (430) 으로 업데이트하도록 신호를 보낼 수도 있다.

http://search/HiddenUserInterface/static?Mode=MORE

예를 들어, 가시적 프레임은 전술한 바와 같이 도 39 상에 나타낸 바와 같은 가시적 유저 인터페이스 (466) 를 이용하여 업데이트될 수도 있다.

도 41 은 예시적인 형태의 컴퓨터 시스템 (500) 의 머신의 도식적 표현이고, 여기 내부에서는 머신이 여기에 논의된 하나 이상의 방법론을 수행하도록 하는 명령들의 셋트가 실행될 수도 있다. 다른 실시형태에서는, 머신은 독립형 디바이스로서 동작하고, 또는 다른 머신들에 접속 (네트워킹) 될 수도 있을 것이다. 네트워크 전개에서, 머신은 서버-클라이언트 네트워크 환경에서는 서버 또는 클라이언트 머신의 용량에서 동작할 수도 있고, 피어-투-피어 (또는 분산형) 네트워크 환경에서 피어 머신으로서 동작할 수도 있다. 머신은 서버 컴퓨터, 클라이언트 컴퓨터, PC, 태블릿 PC, STB (set-top box), PDA, 셀룰러 폰, 웹 적용, 네트워크 라우터, 스위치 또는 브리지, 또는 그 머신에 의해 취해질 행동을 특정하는 명령들의 셋트 (순차적이거나 그외) 를 실행할 수 있는 임의의 머신일 수도 있다. 또한, 오직 단일 머신만을 나타내었지만, "머신" 이라는 용어는 여기에 개시된 임의의 하나 이상의 방법을 수행하기 위해 개별적으로 또는 함께 한 셋트의 (또는 다수 셋트들의) 명령들을 실행하는 머신들의 임의의 집합을 포함하는 것으로 취급될 수도 있다.

예시적인 컴퓨터 시스템 (500) 은 프로세서 (502) (예를 들어, CPU 그래픽 처리 유닛 (GPU) 또는 양자), 메인 메모리 (504) 및 정적 메모리 (506) 를 포함하고, 이들은 버스 (508) 를 통해 서로 통신한다. 컴퓨터 시스템 (500) 은 비디오 표시 유닛 (510) (예를 들어, LCD 또는 CRT) 를 추가로 포함할 수도 있다. 컴퓨터 시스템 (500) 은 또한 문자 숫자식 입력 장치 (512) (예를 들어, 키보드), 커서 제어 장치 (514) (예를 들어, 마우스), 디스크 드라이브 유닛 (516), 신호 생성 장치 (518) (예를 들어, 스피커) 및 네트워크 인터페이스 장치 (520) 를 포함한 다.

디스크 드라이브 유닛 (516) 은 여기에 설명된 하나 이상의 임의의 방법 또는 기능들을 수록한, 하나 이상의 명령들의 셋트들 (예를 들어, 소프트웨어 (524)) 이 저장되는 머신-판독가능 매체 (522) 를 포함한다. 소프트웨어 (524) 는 또한 컴퓨터 시스템 (500) 에 의한 실행 동안 메인 메모리 (504) 내부 및/또는 프로세서 (502) 내부에 완전히 또는 적어도 부분적으로 상주할 수도 있고, 메인 메모리 (504) 및 프로세서 (502) 는 또한 머신-판독가능 매체를 구성한다.

소프트웨어 (524) 는 또한 네트워크 인터페이스 장치 (520) 를 통해 네트워크 (526) 에 대해 송신되거나 수신될 수도 있다.

머신-판독 가능 매체 (522) 가 예시적인 실시형태로서 단일 매체로 나타내어져 있지만, "머신-판독가능 매체" 라는 용어는 하나 이상의 명령들의 셋트들을 저장하는 단일 매체 또는 다수 매체 (예를 들어, 집중 또는 분산 데이터베이스 및/또는 연관 캐시들 및 서버들) 을 포함하는 것으로 취급되어야 한다. "머신-판독가능 매체" 라는 용어는, 머신에 의해 실행될 때 머신으로 하여금 본 발명의 임의의 하나 이상의 방법들을 수행하도록 하는 명령들의 셋트를 저장, 인코딩, 또는 운반할 수 있는 임의의 매체를 포함하는 것으로 취급될 수 있다. "머신-판독가능 매체" 는 고체 메모리, 광학 및 자기 매체, 및 반송파 신호를 포함하는 것으로 취급되어야 하고, 이에 한정되는 것은 아니다.

따라서, 검색 정보 처리 방법 및 시스템을 설명하였다. 본 발명을 특정 실시형태를 참조하여 설명하였지만, 이들 실시형태들에 대한 다양한 수정 및 변형 이 본 발명의 광위의 사상 및 범위로부터 벗어나지 않고서 이루어질 수도 있다는 것은 자명하다. 따라서, 명세서 및 도면들은 한정적 의미가 아니라 예시적으로 간주되어야 한다.

본 발명의 실시형태들은 동일 참조 부호는 동일 구성요소를 나타내는 도면들을 참조한 형태에서 한정적 방식이 아닌 예시적인 방식으로 나타내어져 있다.

도 1 은 데이터 자원을 검색하기 위한, 본 발명에 따른 시스템을 나타낸 블록도이다.

도 2 는 데이터 자원을 검색하기 위한, 일 실시형태에 따른 시스템을 나타내는 네트워크도이다.

도 3 은 본 발명의 일 실시예로, 컴퓨터 기반 시스템의 일부로서 제공되는 다수의 애플리케이션들을 나나태는 블록도이다.

도 4 는 본 발명의 일 실시예에 따른, 네트워크-기반 애플리케이션들을 지원하고, 이들에 의해 이용되는 다양한 테이블들을 나타내는 하이-레벨 엔티티-관계도이다.

도 5 는 본 발명의 일 실시형태에 따른, 데이터 자원의 검색을 용이하게 하는 시스템을 나타내는 블록도이다.

도 6 은 정보 아이템을 분류하기 위한, 일 실시형태에 따른, 검색 애플리케이션들 및 검색 관련 데이터 구조들을 나타내는 블록도이다.

도 7 은 일 실시형태에 따른, 검색 메타데이터를 나타내는 블록도이다.

도 8 은 데이터 자원 검색을 용이하게 하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 9 는 분류 규칙에 따라 정보를 평가하기 위한 방법의 일 실시형태를 나타 내는 블록도이다.

도 10 은 추론 규칙에 따라 정보를 평가하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 11 은 쿼리를 생성하기 위한 시스템의 일 실시형태를 나타내는 블록도이다.

도 12 는 일 실시형태에 따른, 애플리케이션들 검색 및 메타데이터 검색을 나타내는 블록도이다.

도 13 은 데이터 자원을 검색하기 위한 쿼리를 생성하는 방법의 일 실시형태를 나타내는 블록도이다.

도 14 는 키워드 쿼리에 기초하여 도메인을 판정하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 15 는 키워드 쿼리 및 도메인에 기초하여 선택된 특성들을 판정하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 16 은 브라우징에서 데이터 아이템을 식별하기 위한 시스템의 일 실시형태를 나타내는 블록도이다.

도 17 은 일 실시형태에 따른, 검색 애플리케이션과 검색 메타데이터를 나타내는 블록도이다.

도 18 은 일 실시형태에 따른, 분류 엔진을 나타내는 블록도이다.

도 19 는 브라우징에서 데이터 아이템을 식별하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 20 은 일 실시형태에 따른, 선택된 특성들에 기초하여 유저 인터페이스를 생성하기 위한 방법을 나타내는 블록도이다.

도 21 은 선택된 특성들에 기초하여 아이템들의 셋트를 판정하기 위한 방법의 일 실시예를 나타내는 블록도이다.

도 22 는 브라우징 셋트들을 결정하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 23 은 브라우징 값들에 대한 카운트들을 생성하기 위한 방법의 일 실시형태를 나타내는 블록도이다.

도 24 는 일 실시형태에 따른, 유저 인터페이스 및 브라우저 제어를 나타내는 블록도이다.

도 25 는 브라우저 백 버튼을 처리하기 위한 시스템의 일 실시형태를 나타내는 블록도이다.

도 26 은 일 실시형태에 따른, 클라이언트 머신과 연관된 소프트웨어 구성요소를 더 나타내는 블록도이다.

도 27 은 클라이언트 머신에서 백 버튼을 처리하기 위한 방법의 일 실시형태를 나타내는 상호작용 플로우 차트이다.

도 28 은 유저 인터페이스를 요청하기 위한 방법의 일 실시형태를 나타내는 상호작용 플로우차트이다.

도 29a 는 "MORE" 유저 인터페이스 엘리먼트의 유저 선택을 처리하기 위한 방법의 일 실시형태를 나타낸다.

도 29b 는 "ALL" 유저 인터페이스 엘리먼트의 유저 선택을 처리하기 위한 방법의 일 실시형태를 나타낸다.

도 29c 는 백 버튼의 유저 선택을 처리하기위한 방법의 일 실시형태를 나타낸다.

도 30 내지 도 40 은 본 발명의 일 실시예에 따른 유저 인터페이스 화면을 나타낸다.

도 41 은 여기에 개시된 임의의 하나 이상의 방법을 머신이 수행하도록 하는 명령들의 셋트가 실행될 수도 있는 컴퓨터 시스템의 예시적인 형태의 머신의 도해를 나타낸다.

Claims (8)

1. 네트워크-기반 시장에서 판매자에 의해 작성된 목록들을 식별하는데 이용되는 특성들을 취소하는 방법으로서,

   목록들을 식별하는데 이용되는 복수의 특성들을 유저에 전달하는 단계;

   가장 최근에 선택된 특성 이외의 특성을 취소하는 상기 유저로부터 선택을 수신하는 단계;

   상기 선택에 기초하여, 판매자에 의해 입력된 정보의 평가에 기초하여 나머지 특성들을 보이고자 결정된 하나 이상의 목록을 식별하기 위해 상기 가장 최근에 선택된 특성을 포함하는 복수의 나머지 특성들을 식별하는 단계; 및

   상기 복수의 나머지 특성들 및 상기 하나 이상의 목록을 상기 유저에게 전달하는 단계를 포함하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 방법.
2. 네트워크-기반 시장에서 판매자들에 의해 작성된 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템으로서,

   목록들을 식별하는데 이용되는 복수의 특성들을 유저에 전달하기 위한 검색 애플리케이션;

   가장 최근에 선택된 특성 이외의 특성을 취소하는 상기 유저로부터의 선택을 수신하고, 상기 선택에 기초하여, 상기 가장 최근에 선택된 특성을 포함하는 나머지 복수의 특성들을 식별하기 위한 결정 모듈을 포함하고,

   상기 결정 모듈은, 판매자에 의해 입력된 정보의 평가에 기초하여 나머지 특성들을 보이고자 결정된 하나 이상의 목록을 식별하기 위해 복수의 나머지 특성들을 이용하고,

   상기 검색 애플리케이션은, 상기 복수의 나머지 특성들 및 상기 하나 이상의 목록을 상기 유저에게 전달하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템.
3. 제 2 항에 있어서,

   상기 복수의 특성들은 개념-값 쌍을 포함하는 특성들을 포함하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템.
4. 제 2 항에 있어서,

   상기 나머지 특성들은 상기 정보를 분류하는데 이용되는 규칙들 및 부가 정보를 추론하는 규칙들에 기초한 상기 정보와 연관되는, 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템.
5. 제 2 항에 있어서,

   상기 정보는 제목, 설명, 목록 카테고리, 아이템 명세, 가격, 판매 형식, 판매 기간, 옥션 기간, 지불 방법, 운송 정보, 아이템 위치, 및 구매자 요구들을 포함하는 그룹에서 하나 이상을 포함하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템.
6. 제 5 항에 있어서,

   상기 판매 형식은 고정-가격 형식 및 옥션 형식을 포함하는 형식들의 그룹 중 임의의 하나를 포함하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 시스템.
7. 제 1 항에 있어서,

   상기 복수의 특성들은 개념-값 쌍을 포함하는 특성들을 포함하는, 목록들을 식별하는데 이용되는 특성들을 취소하는 방법.
8. 컴퓨터에 의해 실행될 때 상기 컴퓨터로 하여금

   목록들을 식별하는데 이용되는 복수의 특성들을 유저에 전달;

   가장 최근에 선택된 특성 이외의 특성을 취소하는 상기 유저로부터 선택을 수신;

   상기 선택에 기초하여, 판매자에 의해 입력된 정보의 평가에 기초하여 나머지 특성들을 보이고자 결정된 하나 이상의 목록을 식별하기 위해 상기 가장 최근에 선택된 특성을 포함하는 나머지 복수의 특성들을 식별; 및

   상기 복수의 나머지 특성들 및 상기 하나 이상의 목록을 상기 유저에게 전달하도록 하는 명령들의 셋트를 저장하는, 컴퓨터 판독가능 기록매체.

Images