KR20100134478A - 이용자 생성 룰 기반의 다기능 검색창 서비스 제공 방법 및 시스템 - Google Patents

Abstract

본 발명은 다기능 검색창 서비스 제공 방법 및 시스템에 관한 것으로, 더욱 상세하게는 이용자가 생성한 다양한 검색룰과 바로가기를 기반으로 검색 및 바로가기 서비스 제공은 물론, 검색어 입력 시 추천 검색어 및 추천 검색룰을 제시하는 것을 특징으로 하는 다기능 검색창 서비스 제공 방법 및 시스템에 관한 것이다.

이를 위하여 본 발명은 기존 검색 엔진 또는 서비스 서버의 앞 단에 위치하는 검색창 서비스 시스템을 가지는데 상기 검색창 서비스 시스템은

이용자가 입력한 구문과 연관된 검색어를 추천하는 데 활용되는 검색어 추천 DB, 입력된 검색어와 연관되어 쓰이는 검색룰을 추천하는 데 활용되는 검색룰 추천 DB, 이용자별로 설정 정보를 저장하는 개인 설정 정보 DB, 검색창별로 설정 정보를 저장하는 검색창 정보 DB, 이용자들이 직접 등록할 수 있는 검색룰 정보 DB, 및 이용자들이 직접 등록할 수 있는 바로가기 DB 부; 입력 구문을 상기 검색어 추천 DB와 상기 검색룰 추천 DB에 기초하여 검색어와 검색룰의 입력을 돕는 질의어 추천 모듈; 질의어를 상기 개인 설정 정보 DB와 상기 검색창 정보 DB에 기초하여 요소별로 분류하고 복원하는 설정 정보 복원 모듈; 상기 분류되고 복원된 질의어가 명령어인지 파악하고 해당 명령어를 수행하도록 메시지를 구성하는 명령어 분석 모듈;상기 검색룰 정보 DB와 상기 바로가기 DB에 기초하여 상기 설정 정보 복원 모듈 또는 상기 명령어 분석 모듈을 거쳐 분류되고 복원된 질의어를 메시지로 변환하는 메시지 복원 모듈; 상기 메시지 복원 모듈 또는 상기 명령어 분석 모듈로부터 생성된 메시지를 이용자에게 리디렉션 방식으로 돌려주는 리디렉션 모듈; 상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 템플릿 방식으로 돌려주는 템플릿 모듈; 상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 프락시 방식으로 돌려주는 프락시 모듈을 포함하는 것을 특징으로 한다.

검색창, 검색룰, 바로가기, 검색어 추천, 검색룰 추천, 프락시, 템플릿, 리디렉션

Description

이용자 생성 룰 기반의 다기능 검색창 서비스 제공 방법 및 시스템 {User-generated rule based multi-function search box service method and system}

본 발명은 다기능 검색창 서비스 제공 방법 및 시스템에 관한 것으로, 더욱 상세하게는 이용자가 생성한 다양한 검색룰을 기반으로 검색 및 바로가기 서비스 제공은 물론, 검색어 입력 시 추천 검색어 및 추천 검색룰을 제시하는 것을 특징으로 하는 다기능 검색창 서비스 제공 방법 및 시스템에 관한 것이다.

종래의 검색 엔진을 이용한 검색은 검색 결과가 자체 검색 엔진에 국한되었다. 즉 네이버(Naver)의 검색창에 검색어를 입력하면 네이버 검색 엔진만을 이용해서 검색을 수행하기 때문에 그 검색 결과가 상당히 제한적이었다. 하지만 인터넷이 발전할수록 정보의 양은 기하급수적으로 증가하게 되고 하나의 검색 엔진이 모든 정보를 찾는 것은 사실상 불가능하게 되었다. 최근에는 검색 결과가 우수하다는 구글(Google)을 이용하는 사람들이 늘고 있지만 구글의 검색 결과 역시 구글이라는 검색 엔진에 국한되기 때문에 특정 분야에 있어서는 특화된 검색 엔진을 따라오기 어렵다. 예를 들어 블로그(Blog)와 같은 경우 구글을 이용하는 것보다 블로그 전용 검색 엔진을 이용하는 것이 더 유용한 자료를 얻는 경우가 많아졌다.

이러한 문제점을 해소하기 위해 구글에서는 맞춤 검색(Custom Search)을 출시하여, 특정 도메인이나 사이트를 대상으로 가중치를 조절하게 하고 검색 결과를 튜닝(Tuning)할 수 있도록 하였지만 결국 구글 검색 엔진에 의해서만 검색이 이루어진다는 한계를 벗어나지 못했고, 무엇보다 해당 맞춤 검색을 사용하기 위해서는 맞춤 검색별로 별도의 검색창을 만들어서 해당 검색창에서 검색이 이루어져야 하는 단점이 있다. 즉, 하나의 검색창에서 다양한 맞춤 검색을 이용할 수 없고, 검색창 별로 하나의 맞춤 검색만이 이용가능한 제약점이 있다.

또한, 하나의 검색 엔진에 의해서 검색 결과가 국한되는 한계를 넘어서기 위해 아마존(Amazon)의 'A9'과 같이 여러 개의 검색 엔진에서 검색 결과를 가져와서 동시에 화면에 표시해 주는 개방형 검색 서비스가 제시되었지만 A9의 경우, 내가 원하는 검색 엔진을 찾아서 등록하는 과정이 선행되어야 하는데 그 과정이 일반 이용자들에게는 쉽지 않고 구글의 맞춤 검색과 마찬가지로 해당 검색을 사용하기 위해서는 검색 조건별로 별도의 검색창에서 검색이 이루어져야 하는 단점이 있다.

이러한 문제점을 해소하기 위해 본 발명자에 의해 ‘리디렉션 메시지를 이용한 다기능 검색창 서비스 제공 방법 및 시스템’이 이미 출원되어 등록되었지만, 상기 발명의 경우 서비스 제공자 측면에서 설계되어 최근 화두가 되고 있는 이용자 참여에 의한 서비스 강화라는 트렌드를 반영하기 어려운 구조로 되어 있었다. 본 발명에서는 상기 발명의 문제점을 해소하기 위해 이용자가 직접 검색룰을 등록할 수 있도록 함으로써 서비스의 확장성을 강화하고, 이용자별로 보다 맞춤화된 서비 스를 제공하는 것을 특징으로 하고 있다.

본 발명은 상기와 같은 문제점을 해결하기 위해 고안된 것으로 다수의 이용자가 검색룰 및 바로가기를 등록할 수 있도록 하여 서비스의 다양성과 확장성을 높이고 개인화를 강화하여 이용자별로 맞춤형 서비스를 제공하는 데 그 목적이 있다.

또한, 이용자가 검색창에 질의어를 입력할 때 검색어는 물론 해당 검색어와 연관되어 자주 이용되는 검색룰을 추천하는 기능을 제공하여 이용자가 원하는 정보를 보다 빨리 찾을 수 있도록 하는데 그 목적이 있다.

본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있으며 본 발명의 실시 예에 의해 보다 분명하게 알게 될 것이다. 또한, 본 발명의 목적 및 장점들은 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.

상술한 목적을 달성하기 위한 본 발명은, 이용자가 입력한 구문과 연관된 검색어를 추천하는 데 활용되는 검색어 추천 DB, 입력된 검색어와 연관되어 쓰이는 검색룰을 추천하는 데 활용되는 검색룰 추천 DB, 이용자별로 설정 정보를 저장하는 개인 설정 정보 DB, 검색창별로 설정 정보를 저장하는 검색창 정보 DB, 이용자들이 직접 등록할 수 있는 검색룰 정보 DB, 및 이용자들이 직접 등록할 수 있는 바로가기 DB 부; 입력 구문을 상기 검색어 추천 DB와 상기 검색룰 추천 DB에 기초하여 검색어와 검색룰의 입력을 돕는 질의어 추천 모듈; 질의어를 상기 개인 설정 정보 DB 와 상기 검색창 정보 DB에 기초하여 요소별로 분류하고 복원하는 설정 정보 복원 모듈; 상기 분류되고 복원된 질의어가 명령어인지 파악하고 해당 명령어를 수행하도록 메시지를 구성하는 명령어 분석 모듈; 상기 검색룰 정보 DB와 상기 바로가기 DB에 기초하여 상기 설정 정보 복원 모듈 또는 상기 명령어 분석 모듈을 거쳐 분류되고 복원된 질의어를 메시지로 변환하는 메시지 복원 모듈; 상기 메시지 복원 모듈 또는 상기 명령어 분석 모듈로부터 생성된 메시지를 이용자에게 리디렉션 방식으로 돌려주는 리디렉션 모듈; 상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 템플릿 방식으로 돌려주는 템플릿 모듈; 상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 프락시 방식으로 돌려주는 프락시 모듈을 포함하는 것을 특징으로 한다. 상기 검색룰 정보DB는 검색룰 추천 DB에 저장되어 있는 검색룰별로 상이한 ID를 부여하고, 검색룰 ID에 기초하여 각 검색룰에 대하여 평점, 이용횟수, 채택횟수, 스폰서 여부, IP주소를 등록하여 저장하는 것을 특징으로 한다. 또한, 상기 검색룰 정보 DB는 각 검색룰에 별도의 ID를 부여하여 검색룰을 구별하고, 각 검색룰에 대하여 평점, 이용횟수, 채택횟수, 스폰서 여부 등의 정보를 저장하며, 각 검색룰에 해당하는 IP주소를 저장하여 등록하는 것을 특징으로 한다.

본 발명의 개인 설정 정보 DB에는, 기본 구분자가 ‘at’으로 등록되어 있고, 이용자의 선택에 따라 ‘>>’등의 기호나 ‘앳' 등의 문자를 등록할 수 있는 것을 특징으로 한다.

또한, 본 발명의 질의어 추천 모듈은, 상기 검색어 또는 검색룰 추천 단계에 있어서 스폰서가 있는 검색어 또는 검색룰을 추천 영역의 상단에 표시하여 이용자 의 선택을 유도하고, 이용자 선택 시 스폰서별로 선택 횟수를 상기 검색어 추천 DB 또는 상기 검색룰 추천 DB에 저장하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명에 따른 검색창 서비스 방법의 실시형태는, 이용자로부터 질의어를 입력받는 입력 단계; 완성된 질의어를 상기 개인 설정 정보 DB와 상기 검색창 정보 DB에 기초하여 요소별로 분류하고 복원하는 설정 정보 복원 단계; 상기 검색룰 정보 DB에 기초하여 분류되고 복원된 질의어를 메시지로 복원하는 메시지 복원 단계; 복원된 메시지를 이용자에게 돌려주는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명의 입력 단계는, 이용자가 입력한 구문과 관련하여 검색어 추천 DB가 추천한 검색어를 선택하는 경우 또는 입력 구문이 검색어만으로 이루어진 경우 상기 검색룰 추천 DB에 기초하여 구분자를 포함한 검색룰이 추천되면, 추천되는 검색룰 중 상기 개인 설정 정보 DB에 등록된 기본 검색룰을 선택하면 기본 검색룰을 입력하는 단계; 추천하는 검색룰 중 상기 개인 설정 정보 DB에 등록된 채택룰을 선택하면 해당 채택룰을 입력하는 단계; 추천하는 검색룰 중 기본 검색룰 또는 채택룰이 아닌 검색룰을 선택하면 상기 개인 설정 정보 DB에 등록된 선택 기준에 부합하는 검색룰을 입력하는 단계; 및 추천하는 검색룰 중 어느 검색룰도 선택하지 않으면 기본 검색룰을 입력하는 단계를 거쳐 완성된 질의어를 입력받는 단계를 포함할 수 있다.

또한, 본 발명의 설정 정보 복원 단계는, 상기 복원된 질의어에 명령어가 포함되어 있으면 명령어 분석을 통하여 바로가기 명령어인 경우 상기 바로가기 DB에 기초하여 바로가기 명령을 실행하는 단계; 바로가기 이외의 명령어인 경우 해당 명 령어를 실행하는 단계를 포함할 수 있다.

또한, 본 발명의 설정 정보 복원 단계는, 상기 복원된 질의어에 구분자가 없고 검색창에 상기 검색창 정보 DB에 설정된 기본 검색룰이 있다면 기본 검색룰을 선택하는 단계; 상기 복원된 질의어에 구분자가 없고 검색창에 기본 검색룰이 없다면 상기 개인 설정 정보 DB에 설정된 이용자 기본 검색룰을 선택하는 단계; 상기 복원된 질의어에 구분자가 없고 검색창에 기본 검색룰이 없으며 상기 개인 설정 정보 DB에 설정된 이용자 기본 검색룰이 없다면 글로벌 기본 검색룰을 선택하는 단계; 상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있지 않으면 신규 검색룰을 등록하는 페이지로 URL을 지정하여 메시지를 복원하는 메시지 복원 단계; 상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있으며 이용자가 해당 검색룰을 채택하여 상기 개인 설정 정보 DB에 저장되어있다면 이용자가 채택한 검색룰을 선택하는 단계; 상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있으며 이용자가 채택하지 않았다면 상기 개인 설정 정보 DB에 저장되어 있는 검색룰 선택 기준에 기초하여 검색룰을 선택하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명의 복원된 메시지를 이용자에게 돌려주는 단계는,

서비스 서버로 상기 검색창 서비스 시스템이 검색어를 전송한 후 결과를 받아서 재구성하여 이용자의 화면에 전송하는 프락시 방식으로 하는 단계;

템플릿을 생성해 전송하고 이용자의 컴퓨터가 서비스 서버로부터 직접 결과를 받아 와서 이용자의 화면에 표시하는 템플릿 방식으로 하는 단계; 검색룰에 따라 URL을 복원하여 이용자 화면에 표시하는 리디렉션 방식으로 하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명의 메시지 복원 단계는, 상기 개인 설정 정보 DB에 기초하여 URL 중 서버 주소 부분을 IP 주소로 치환하여 보내는 단계를 포함할 수 있다.

상기와 같은 본 발명에 따르면, 이용자 입장에서는 크라우드 소싱(Crowd Sourcing)에 의해 축적된 풍부한 검색룰 및 바로가기를 손쉽게 이용할 수 있으며, 개인화 기능에 의해 같은 이름을 가지는 검색룰 및 바로가기 중에서도 자신에게 꼭 맞는 것을 채택하여 이용할 수 있게 된다. 또한 검색어 및 검색룰 추천 기능을 이용할 경우 검색어 추천뿐 아니라, 검색어 별로 가장 많은 사람들이 이용하거나 채택한 검색룰을 통해 검색할 수 있게 되어 원하는 검색 결과를 보다 손쉽고 빠르게 얻을 수 있게 된다.

사업자 측면에서는 인터넷 익스플로러나 파이어폭스와 같은 브라우저의 기본 검색 엔진으로 지정됨으로써 이용자가 증가해 영향력이 커지면서 광고 효과가 증대되는 효과가 있고 백업 DB에 저장된 인기 검색어 통계 기능을 이용해 이용자들의 요구에 효과적으로 대처할 수 있게 된다. 또한 추천 시 우선 노출, 매출 연계 수익 배분 등 다양한 수익 모델을 적용하는 것이 가능하여 높은 수익을 기대할 수 있다.

본 발명의 구성과 작동 방법에 대하여 도면을 통하여 상세히 설명하기로 한 다.

도 1은 질의어 분석 시스템의 구조를 나타낸다. 질의어 분석 시스템은 검색창을 통해 입력된 질의어를 분석하여 그에 맞는 동작이 이루어지도록 메시지를 생성하는 역할을 하게 된다. 이를 위해 입력된 질의어는 질의어 추천 모듈, 설정 정보 복원 모듈, 명령어 분석 모듈, 메시지 복원 모듈, 프락시 모듈, 템플릿 모듈, 리디렉션 모듈을 거치게 되며, 그 과정에서 각 모듈은 필요에 따라 검색어 추천 DB, 검색룰 추천 DB, 개인 설정 정보 DB, 검색창 정보 DB, 검색룰 정보 DB, 바로가기 정보 DB를 참조하게 된다.

이해를 돕기 위해 간단한 예제를 들어 설명하면, 검색창에 ‘mp3 at google’이라는 질의어가 들어왔다고 가정하자. 이 질의어는 ‘mp3’라는 검색어를 ‘google’이라는 검색룰을 통해 검색한 결과를 브라우저에 표시하라는 의미이다.

먼저, 질의어 추천 모듈은 ‘mp3’라는 검색어에 대해 추천을 수행한다. 이용자가 검색창에 ‘m’을 입력하는 순간 질의어 추천 모듈은 검색어 추천 DB를 조회하여 ‘myspace’, ‘msn’, ‘mp3’와 같이 m으로 시작하는 단어들을 검색창 하단에 추천하게 되는데 이와 같은 기능은 현재 많은 검색 엔진에서 활용되고 있는 방법이다.

이용자가 제시된 추천 검색어 중에서 ‘mp3’를 선택한 경우 질의어 추천 모듈은 검색룰 추천 DB를 조회하여 2단계 추천을 시작하게 되는데 2단계 추천은 ‘mp3’라는 검색어에 대해 해당 이용자가 자주 이용하는 검색룰, 전체 이용자들이 가장 많이 선택한 검색룰 또는 최근에 많이 선택하는 추세에 있는 검색룰들을 추천 하게 된다. 이용자들이 ‘google’, ‘amazon’, ‘itunes’와 같은 검색룰들을 ‘mp3’와 함께 많이 선택했다면 해당 검색룰들이 추천되어 추천 영역에는 ‘mp3 at google’, ‘mp3 at amazon’, ‘mp3 at itunes’와 같은 추천 질의어가 표시되게 될 것이다. 여기서 ‘at’은 검색어와 검색룰을 구분하는 구분자로서 이용자가 개인 설정 정보에서 선택할 수 있게 된다. 이용자별로 ‘at’대신에 ‘앳’를 사용하거나 ‘>>’와 같은 기호를 지정할 수 있을 것이다.

이 때 검색어와 검색룰은 본 서비스가 검색 서비스에 가장 유용하게 쓰일 수 있기 때문에 검색어와 검색룰이라는 용어를 사용한 것으로, 검색 서비스에 국한되지 않고 파라메터 입력을 갖는 모든 서비스에 적용될 수 있다. 예를 들어, ‘I am busy today at miniblog’와 같은 질의어는 ‘I am busy today’라는 문구를 ‘miniblog’라는 미니 블로그에 포스팅(Posting)하는 동작을 할 수 있다. 또한 검색룰은 서비스의 이름과 꼭 같을 필요는 없는데 예를 들어 ‘miniblog’라는 검색룰은 해외에서 많이 이용되고 있는 ‘twitter’에 글을 포스팅하는 룰일 수도 있고, 국내에서 많이 이용되고 있는 ‘미투데이’에 글을 포스팅하는 룰일 수도 있다. 요컨대, 어떤 이름을 가진 검색룰을 처음 등록하는 이용자가 임의로 이름을 정할 수 있고, 같은 이름을 가진 검색룰이 다수 존재할 수 있게 된다. 이러한 다수의 검색룰 중에서 어떤 것을 채택(Adoption)할 지는 이용자가 결정을 하게 되며 이러한 정보는 개인 설정 정보 DB에 저장되게 된다. 여기서 채택이라는 과정은 동일한 이름을 갖는 여러 검색룰 중에서 이용자가 하나를 선택하여 저장해 두는 과정으로 하나의 이름에 대해서 하나의 검색룰만 채택이 가능하다.

설정 정보 복원 모듈은 개인 설정 정보 DB와 검색창 정보 DB를 조회하여 개인별로, 검색창별로 설정된 정보를 복원하게 된다. 예를 들어 검색룰이 지정되지 않았을 경우 기본 검색룰을 이용하여 검색을 수행하게 되는데 ‘google’을 기본 검색룰로 정해놓은 이용자는 해당 검색룰을 통해, ‘naver’를 기본 검색룰로 정해놓은 이용자는 해당 검색룰을 통해 검색이 이루어지게 된다.

만약 ‘video’이라는 검색룰이 입력되었는데, 해당 이용자가 ‘video’라는 검색룰에 대해 따로 채택을 하지 않았고, ‘video’라는 이름을 가지는 검색룰이 유투브(www.youtube.com)에서 동영상을 검색하는 검색룰과, 네이버 비디오(video.naver.com)에서 동영상을 검색하는 검색룰이 있다면, 이용자가 기설정해 놓은 선택 기준에 따라 검색룰이 선택되게 되는데, 검색룰 선택기준은 최다 이용 기준, 최다 채택 기준, 최다 평점 기준, 스폰서 유무 기준 등이 될 수 있을 것이다.

여기서 개인 설정 정보 DB와 검색창 정보 DB를 분리한 이유는, 브라우저 우측 상단에 있는 인스턴트 검색창과 블로그에 삽입되는 검색창을 구분하기 위한 것인데, 일반적으로 인스턴트 검색창은 개인별로 기본 검색룰이 모두 다른 반면, 블로그에 삽입되는 검색창은 해당 블로그를 대상으로 검색하는 것이 기본 검색룰로 정해지는 경우가 많을 것이다.

설정 정보 복원 모듈에서는 구분자에 대한 복원도 수행하게 된다. 앞서 예를 든 바와 같이 ‘at’을 구분자로 쓰는 이용자도 있고, ‘>>’를 구분자로 쓰는 이용자도 있을 텐데 입력된 질의어에서 구분자를 찾아내는 역할도 설정 정보 복원 모 듈에서 일어나게 된다.

명령어 분석 모듈은 본 서비스에서 이용되는 명령어들에 대한 처리를 담당하게 되는데 명령어들은 ‘/login’, ‘/logout’, ‘/default’, ‘/list’, ‘/go’ 등이 있을 수 있다. 명령어 별로 간단히 살펴보면 ‘/login username’은 해당 ‘username’을 갖는 이용자가 패스워드(Password)를 입력할 수 있는 로그인 페이지로 이용자를 이동시키는 역할을 하고, ‘/logout’은 현재 로그인되어 있는 이용자를 로그아웃시키고 로그아웃 페이지로 이동시키는 역할을 수행한다. ‘/default rulename’은 ‘rulename’으로 기본 검색룰을 지정할 수 있도록 하고, ‘/list rulename’은 해당 ‘rulename’을 갖는 검색룰을 모두 표시하는 역할을 수행한다. ‘/go shortcutname’은 ‘shortcutname’이라는 이름을 갖는 바로가기가 가리키는 주소로 바로가기를 수행한다.

메시지 복원 모듈은 검색룰 정보 DB와 바로가기 정보 DB를 조회하여 메시지를 복원하는 역할을 수행하게 되는데, 앞서 설정 정보 복원 모듈을 통해 채택된 검색룰 또는 바로가기를 기준으로 수행되게 된다. 여기서 검색룰 정보 DB와 바로가기 정보 DB가 분리되어 있는데 검색룰 정보 DB에는 검색어와 같은 파라메터(Parameter)가 필요한 URL(Unified Resource Locator)이나 코드(Code)같은 메시지가 저장되고, 바로가기 정보 DB에는 파라메터가 필요없는 URL 메시지가 저장된다. 이 때 URL과 코드의 차이는 URL은 한 개의 서비스 서버만을 지정할 수 있는 반면, 코드는 복수 개의 서비스 서버를 지정하는 것은 물론 템플릿의 형태나, 질의어 분석 시스템이 수행해야 하는 프로그램까지를 포함할 수 있다는 점이다.

쉽게 예를 들어 설명하면, 검색룰 정보 DB에는 ‘google’이라는 검색룰에 대해 ‘http://www.google.com/search?query=TEST’라는 URL이 매칭되어 저장되어 있고, 여기서 ‘TEST’는 입력된 파라메터로 치환되게 된다. 즉 ‘mp3 at google’과 같은 질의어는 ‘http://www.google.com/search?query=mp3’로 변환되어 구글로 전달되어 검색이 이루어지게 되는 것이다. 반면에 바로가기 정보 DB에는 ‘google’이라는 바로가기에 대해 ‘http://www.google.com’과 같은 URL이 매칭되어 저장되게 되는데 여기에는 파라메터가 들어갈 수 있는 자리가 없다. 즉, ‘/go google’과 같은 바로가기 명령어는 ‘http://www.google.com’으로 변환되어 페이지 이동이 일어나게 된다.

이러한 검색룰 변환 및 바로가기 변환 과정에서 ‘http://www.google.com’과 같은 URL을 클라이언트로 보내게 되면 클라이언트 측에서 ‘www.google.com’에 대한 IP주소를 또 한번 DNS 서버에 조회하게 되어 지연이 발생할 수 있는데, 이러한 지연을 감소시키기 위해 ‘www.google.com’에 대한 IP주소를 미리 검색룰 정보 DB에 저장해 두고, 이용자의 개인별 설정에 따라 ‘http://www.google.com’이 아닌 ‘http://74.125.127.103’으로 전달하여 지연을 감소시키는 방법도 고려해볼 수 있다. 다만 이렇게 할 경우 이용자가 현재 접속 중인 사이트가 제대로 된 사이트인지 피싱 사이트인지 구분하기 어려운 단점이 있다.

이용자의 질의어에 대한 검색 결과를 이용자의 브라우저에 전달하는 방법은 3가지로 나누어 구현될 수 있는데, 리디렉션 메시지를 이용하는 방법, 결과 페이지 템플릿을 생성해서 전달하는 방법, 프락시로 페이지를 재구성하여 전달하는 방법이 그것이다.

먼저 리디렉션 메시지를 이용하는 방법은 가장 간단한 방법으로 리디렉션 모듈에 의해 수행되게 된다. 앞서 예를 든 것과 같이 ‘mp3 at google’이라는 이용자의 질의어가 ‘http://www.google.com/search?query=mp3’라는 URL로 변환되어 구글로 리디렉션되는 방식이다. 리디렉션 방식의 장점은 질의어 분석 시스템의 부하를 최소화할 수 있으며, 이용자가 검색룰을 생성하기도 가장 용이하다는 점이다. 하지만 검색 결과를 니즈(Needs)에 맞게 재구성하기 어렵다는 단점이 있다.

다음으로 결과 페이지 템플릿을 생성해서 전달하는 방법은 질의어 분석 시스템의 부하를 최소화하면서 검색 결과를 어느 정도 재구성하는 효과를 거둘 수 있는 방법으로 템플릿 모듈에 의해 수행된다. 예를 들어 결과 페이지를 3개의 프레임 영역으로 나누어 첫째 영역에는 오버추어(www.overture.com)를 통해 광고를 가져와 노출하고, 두 번째 영역에는 구글을 통해 검색결과를 가져와 노출하고, 세 번째 페이지에는 네이버(www.naver.com)을 통해 검색결과를 가져와 노출하는 방식이다. 이 방법을 이용하기 위해서는 일반적으로 검색엔진에서 공개된 API(Application Programming Interface)를 이용하게 된다.

마지막으로 프락시로 페이지를 재구성하여 전달하는 방법은 질의어 분석 시스템의 부하는 크지만 검색 결과를 원하는 대로 재구성할 수 있는 방법으로 프락시 모듈에 의해 수행된다. 앞서 템플릿을 생성해서 전달하는 방법에서 질의어 분석 시스템이 각 영역만을 구분해주고, 각 영역을 채우는 역할을 브라우저에게 맡기는 반면, 프락시로 페이지를 재구성하여 전달하는 방법은 각 영역을 구분하는 방법 뿐만 아니라 각 영역을 채우는 역할까지도 질의어 분석시스템에서 수행하게 된다. 그만큼 질의어 분석 시스템의 부하는 커지게 되지만 그 대신 검색 결과를 원하는 만큼 재구성하는 것이 가능하게 된다. 본 발명에 따른 질의어 분석 시스템의 경우 3가지 방법을 모두 지원하여 필요에 따라 적절한 것을 이용할 수 있게 하는 것을 특징으로 한다.

도 2는 클라이언트가 브라우저의 주소창을 통해 입력한 질의어가 상기 질의어 분석 시스템을 통해 리디렉션 메시지 생성을 통해 처리되는 과정을 나타낸다. 주소창에 입력된 질의어의 경우 먼저 DNS(Domain Name Service) 서버를 거치게 되는데 DNS 서버를 통해 제대로 된 주소인지 아닌지를 검증하게 된다. 만약 제대로 된 주소일 경우 해당하는 IP주소를 보내어 해당 IP주소로 접속이 이루어지게 되지만, 그렇지 않을 경우에는 잘못된 주소라는 메시지로 클라이언트의 브라우저에 응답하여 브라우저에서 기 설정한 기본 검색 엔진을 통하여 검색이 이루어지게 된다.

이 경우 기본 검색 엔진으로 이용자가 원하는 검색 엔진을 설정할 수 있는데 만약에 상기 구문 분석 시스템이 기본 검색 엔진으로 지정되어 있을 경우에는 구문 분석 시스템에서 입력 구문을 분석하여 적절한 서비스 서버로 접속할 수 있도록 리디렉션 메시지를 보내게 된다. 또한 이 과정에서 분석된 입력 구문을 내부 또는 외부에 있는 로그 DB에 저장 해 둠으로써 향후에 검색어 추천 DB 생성, 검색룰 추천 DB 생성, 인기 검색어 통계 등에 활용할 수 있게 된다. 만약 브라우저의 인스턴트 검색창이나 홈페이지의 검색창을 이용한다면 도 2의 1번(DNS 서버 요청)과 2번(DNS 서버 응답) 과정이 없이 바로 3번(지정된 기본 검색 엔진으로 입력값 전달) 과정부 터 진행이 될 것이다.

상기 질의어 분석 시스템의 질의어는 상기 질의어 분석 시스템이 구현된 서버의 홈페이지의 검색창을 통해 입력받거나 외부에 링크로 연결된 검색창을 통해 입력을 받을 수 있지만, 전술한 바와 같이 브라우저의 주소창이나 인스턴트 검색창을 통해 바로 입력을 받을 경우 상기 질의어 분석 시스템의 이용이 크게 증대될 수 있을 것이다. 또한 야후(Yahoo), 네이버와 같은 포탈 사이트에서 제공하는 검색툴바의 검색창이나 향후 출시될 윈도우 7과 같은 운영체제의 검색창으로부터도 입력이 가능하다. 요컨대 상기 질의어 분석 시스템은 모든 형태의 검색창과 연동하여 제공되는 것이 가능하다.

또한 상기 질의어 분석 시스템은 기존의 검색 엔진 사이트나 서비스 사이트와 별도의 사이트에 구현될 수도 있지만 기존 검색 엔진 사이트에 통합하여 구현될 수도 있다.

도 3은 클라이언트가 브라우저의 주소창을 통해 입력한 질의어가 상기 질의어 분석 시스템에서 결과 페이지 템플릿을 생성하여 전달하는 방법으로 처리되는 과정을 나타낸다. 도 2의 리디렉션 메시지 생성 방법과 달리 페이지 템플릿을 생성할 경우 복수 개의 서비스 서버로부터 검색 결과를 받아서 클라이언트에서 재구성하는 것이 가능하다. 질의어 분석 시스템은 클라이언트에게 결과 페이지 템플릿을 전달하고 각각의 서비스 서버에 접속해서 템플릿 안의 내용을 채우는 일은 클라이언트에서 담당하게 된다.

도 4는 클라이언트가 브라우저의 주소창을 통해 입력한 질의어가 상기 질의 어 분석 시스템에서 프락시로 페이지를 재구성하여 전달하는 방법으로 처리되는 과정을 나타낸다. 도 3의 결과 페이지 템플릿 생성 방법과 달리 프락시로 페이지를 재구성하여 전달하는 방법의 경우 클라이언트가 아닌 질의어 분석 시스템이 각각의 서비스 서버에 검색어를 전달하고 결과를 받아 재구성하여 클라이언트에 전달하게 된다. 이 때문에 검색 결과에 대해 원하는 대로 재구성이 가능한 특성을 갖는다.

도 5는 질의어 분석 시스템의 처리 순서도를 나타낸다. 먼저 입력된 질의어에 대해 검색어 추천이 일어나게 되고 검색어 추천 이후에 검색룰 추천이 이루어지게 된다. 그 이후에는 설정 정보 복원 과정을 수행하여 개인별로 검색창별로 설정된 기본 검색룰이나 구분자를 선택하는 과정이 이루어진다. 이후에 구문을 분석하여 지정된 명령어가 있을 경우 명령어별로 지정된 작업이 수행되게 되고 명령어가 ‘go shortcutname’의 형태의 바로가기라면 바로가기 정보 DB를 통해 URL 복원이 일어나게 된다.

명령어 분석 이후에는 구분자가 존재하는 지를 체크하여 구분자가 존재하지 않을 경우 개인별, 검색창별로 지정된 기본 검색룰에 따라 URL 복원, 코드 생성 등의 메시지 생성 과정이 일어나게 되며, 검색룰이 지정된 경우에는 다시 해당 검색룰이 이미 등록되어 있는 검색룰인지, 아직 등록되지 않은 검색룰인지 체크하는 과정이 일어나게 된다. 이 때 검색룰이 이미 등록되어 있다면 해당 검색룰에 따라 URL이나 코드와 같은 메시지가 생성되게 되고, 아직 등록되어 있지 않다면 신규 검색룰 등록 페이지로 이용자를 이동시킬 수 있도록 해당 URL이 지정되게 된다.

검색룰에 따라 생성된 메시지는 앞서 살펴본 바와 같이 프락시 방식, 템플릿 방식, 리디렉션 방식에 따라 이용자에게 전달되는 방법이 달라지는데 먼저 프락시 방식인지 여부를 체크하게 된다. 만약 프락시 방식으로 검색 결과를 전달하도록 설정되어 있다면, 질의어 분석 시스템의 프락시 모듈에서 메시지에 지정되어 있는 서비스 서버로 검색어를 전달한 후 검색 결과를 받아서 결과를 재구성하여 이용자 화면에 표시하게 된다. 이때 이용자 화면에 표시하는 방법은 현재 창에 표시하는 방법, 새 창에 표시하는 방법, 팝업으로 표시하는 방법 등이 있을 수 있는데 개인 설정 정보 DB에 선호하는 표시 방법을 개인별로 설정해두거나 검색룰 정보 DB에 표시 방법을 설정해 둘 수 있다. 또는 ‘to’와 같은 제 2의 구분자를 두어 ‘mp3 at google to new’의 형태로 ‘mp3’를 ‘google’이라는 검색룰에 의해 검색한 결과를 새 창에 표시하도록 이용자가 질의어 상에 지시하게 할 수도 있다.

프락시 방식이 아닐 경우 템플릿 방식인지를 체크하게 되는데, 템플릿 방식의 경우 결과 페이지 템플릿을 생성하여 브라우저에 전달하면 나머지 과정은 브라우저에서 수행하게 된다.

템플릿 방식도, 프락시 방식도 아닌 경우에는 리디렉션 방식이 수행되게 되는데 리디렉션 방식은 가장 간단한 방법으로 복원된 URL을 브라우저에 전달하면 브라우저에서 해당 URL에 접속하는 방식으로 작업이 수행되게 된다.

도 6은 검색룰 선택 순서도로서, 상기 도 5에서 구분자가 존재하는지 체크하는 과정과 검색룰이 존재하는지를 체크하는 과정에서 검색룰이 선택되는 과정을 상세하게 나타내고 있다.

먼저 구분자가 존재하지 않는 경우에는 기본 검색룰을 이용하여 검색이 이루 어져야 하므로 기본 검색룰을 선택하는 과정이 필요한데, 이때 기본 검색룰을 선택하기 위해서는 먼저 검색창에 지정된 기본 검색룰이 있는지 체크하여 있을 경우 해당 검색룰을 기본 검색룰로 선택하게 되고, 그렇지 않을 경우 이용자가 지정한 기본 검색룰이 있는지 체크하여 있을 경우 해당 검색룰을 기본 검색룰로 선택하게 된다. 만약 이용자가 누구인지 알 수 없는 경우나 기본 검색룰을 지정하지 않은 경우에는 글로벌하게 지정된 기본 검색룰을 선택하게 된다. 이때 지역별로 다른 기본 검색룰을 지정할 수도 있는데 예를 들어 국내의 경우 가장 많이 이용되는 네이버를 기본 검색룰로 설정할 수 있고, 해외의 경우 가장 많이 이용되는 구글을 기본 검색룰로 설정하는 것이 가능하다.

질의어에 검색룰이 지정되어 있고 해당 검색룰이 이미 등록되어 있을 때, 만약 해당 이름을 가지는 검색룰이 하나 이상 있을 경우에는 먼저 이용자가 해당 이름의 검색룰을 이미 채택했는지를 체크하여 그럴 경우 이용자가 채택한 검색룰을 선택하게 되지만, 그렇지 않을 경우 이용자의 검색룰 선택 기준을 따르게 된다. 만약 최고평점을 선택 기준으로 지정해 두었다면, 해당 이름을 갖는 검색룰 중에서 이용자들의 평가가 가장 좋은 검색룰을 선택하게 되고, 최다이용을 선택 기준으로 지정해 두었다면, 해당 이름을 갖는 검색룰 중에서 가장 많이 이용된 검색룰을 선택하게 된다. 또한 최다채택을 선택 기준으로 지정해 두었다면 해당 이름을 갖는 검색룰 중에서 가장 많이 채택된 검색룰이 선택되며, 스폰서를 선택 기준으로 지정해 두었다면 해당 이름을 갖는 검색룰 중에서 스폰서가 있는 검색룰을 선택하게 된다. 예를 들어, ‘a’라는 검색룰 이름에 대해 아마존(www.amazon.com)과 어바웃(www.about.com)에서 각각 검색룰을 등록해 놓았는데, 어바웃이 스폰서 비용을 지불한다면 아마존이 더 많이 이용되어도 어바웃이 선택되는 것이다.

도 7은 상기 질의어 분석 시스템의 질의어 추천 모듈에서의 검색어와 검색룰의 2단계 추천 방법을 나타낸다. 이용자가 검색창에 ‘m’을 입력하게 되면 질의어 추천 모듈은 검색어 추천 DB를 조회하여 ‘m’으로 시작하는 다양한 검색어가 추천 영역에 표시되게 되는데 이때 추천 영역의 최상단에 스폰서 영역을 두어 ‘m’이라는 단어에 대해 스폰서 비용을 지불한 스폰서의 검색어를 상위에 노출하여 이용자가 쉽게 선택하도록 유도할 수 있다. 만약 추천된 검색어 중 하나가 선택되었다면 해당 검색어에 대해 검색룰을 추천하게 되는데 검색룰 추천은 질의어 추천 모듈이 검색룰 추천 DB를 조회하여 이루어지게 된다. 해당 검색어와 어떤 검색룰이 함께 이용된 경우가 많은 지를 로그 DB로부터 추출하여 재구성함으로써 Ajax (Asynchronous Java Script and XML) 방식으로 제공이 가능하다. 검색룰 추천의 경우에도 추천 영역의 최상단에 스폰서의 검색룰을 노출하여 이용자가 쉽게 선택하도록 유도할 수 있다. 이렇게 스폰서 검색어 또는 스폰서 검색룰이 선택된 횟수를 검색어 추천 DB와 검색룰 추천 DB에 저장하여 향후 스폰서로부터 우선 노출에 대한 댓가를 받는 데 활용할 수 있다.

또한 검색어와 검색룰을 추천할 때는 주어진 입력값을 기준으로 일반적으로 사람들이 해당 입력값을 입력한 후 어떤 검색어와 검색룰을 많이 선택하는 지를 기준으로 우선적으로 추천할 수도 있으며, 이용자별로 또는 검색창별로 많이 쓰이는 검색어와 검색룰을 우선적으로 추천할 수도 있다.

각각의 단계는 별개로 또는 함께 이루어질 수 있다. 즉, 현재 대부분의 검색엔진에서 하듯이 검색어 추천만을 제공할 수도 있고, 본 발명에 따른 질의어 분석 시스템의 특성을 살려 검색룰 추천만을 제공할 수도 있으며, 둘 다 함께 제공하는 것도 가능하다. 또한 각각의 단계 모두에 이용자가 스폰서의 검색어 또는 검색룰을 선택할 경우 스폰서로부터 일정액의 대가를 받는 수익모델을 생각할 수 있다.

도 8은 상기 검색창 서비스 시스템을 이용한 질의어 처리 결과의 간단한 예를 나타낸다. 검색룰 정보 DB를 보면 검색룰 이름 외에 검색룰 ID가 있는데 이 검색룰 ID가 검색룰 별로 유일한 값이 된다. 또한 검색룰 별로 평점, 이용횟수, 채택횟수, 스폰서 여부가 기록되어 동일한 이름을 갖는 검색룰 간에 선택 조건으로 활용되며, URL이나 코드의 형태로 표시되는 검색룰 역할 항목이 있고, DNS 조회 단계를 줄이기 위한 검색 서버의 IP주소가 기록되어 있다.

개인 설정 정보 DB에는 이용자가 선택한 기본 검색룰 ID값과 채택한 룰들의 ID값, 동일한 이름을 가진 검색룰의 선택 기준, 구분자, IP주소 직접받기 사용여부 등이 기록되어 있다.

질의어 별로 살펴보면 먼저 1번 질의어인 ‘mp3’의 경우 검색룰이 지정되어 있지 않으므로 이용자가 기본 검색룰로 선택한 검색룰 ID가 100321인 google이라는 이름을 갖는 검색룰에 의해 검색을 수행한다. 2번 질의어인 ‘mp3 at google’의 경우 google이라는 이름을 갖는 검색룰 중 100321 검색룰이 선택되어 검색이 이루어지며, 3번 질의어인 ‘mp3 at a’는 a라는 이름을 갖는 검색룰을 이용자가 채택하지 않았기 때문에 이용자가 지정한 검색룰 선택 기준인 ‘최다 이용’의 기준에 따라 234322 검색룰이 선택되어 검색이 이루어지게 된다. 4번 질의어인 ‘mp3 >> ebay’의 경우 이용자가 ‘>>’를 구분자로 지정해 놓았기 때문에 ebay라는 이름을 갖는 312134 검색룰을 통해 검색이 이루어지게 되고, 5번 질의어인 ‘mp3 앳 a’의 경우 이용자가 ‘앳’을 구분자로 지정하지 않았기 때문에 구분자가 없어 ‘mp3 앳 a’를 기본 검색룰인 100321 검색룰을 통해 검색하게 된다. 이 때 at과 같은 구분자가 검색어에 꼭 들어가야 하는 경우에는 at 을 큰따옴표로 싸서 ‘education “at” Harvard at google’과 같은 형태로 해서 구분자가 아니라 검색어의 일부임을 나타낼 수 있을 것이다.

도 1은 본 발명에 따른 검색창 서비스 시스템의 구조도.

도 2는 본 발명에 따른 검색창 서비스 시스템에서의 주소창 입력 질의어에 대한 리디렉션 방식에 의한 질의어 처리 방법도.

도 3은 본 발명에 따른 검색창 서비스 시스템에서의 주소창 입력 질의어에 대한 템플릿 생성 방식에 의한 질의어 처리 방법도.

도 4는 본 발명에 따른 검색창 서비스 시스템에서의 주소창 입력 질의어에 대한 프락시 방식에 의한 질의어 처리 방법도.

도 5는 본 발명에 따른 검색창 서비스 시스템의 처리 순서도.

도 6은 본 발명에 따른 검색창 서비스 시스템의 검색룰 선택 순서도.

도 7은 본 발명에 따른 검색창 서비스 시스템의 검색어와 검색룰의 2단계 추천 방법 실시예 설명도.

도 8은 본 발명에 따른 검색창 서비스 시스템의 입력된 질의어의 처리 실시예 설명도.

* 도면의 주요 부분에 대한 부호 설명

300 : 검색창 서비스 시스템 301 : 검색어 추천 DB

302 : 검색룰 추천 DB 303 : 개인 설정 정보 DB

304 : 검색창 정보 DB 305 : 검색룰 정보 DB

306 : 바로가기 정보 DB 311 : 질의어 추천 모듈

312 : 설정 정보 복원 모듈 313 : 명령어 분석 모듈

314 : 메시지 복원 모듈 315 : 리디렉션 모듈

316 : 템플릿 모듈 317 : 프락시 모듈

Claims (9)

1. 이용자가 입력한 구문과 연관된 검색어를 추천하는 데 활용되는 검색어 추천 DB, 입력된 검색어와 연관되어 쓰이는 검색룰을 추천하는 데 활용되는 검색룰 추천 DB, 이용자별로 설정 정보를 저장하는 개인 설정 정보 DB, 검색창별로 설정 정보를 저장하는 검색창 정보 DB, 이용자들이 직접 등록할 수 있는 검색룰 정보 DB, 및 이용자들이 직접 등록할 수 있는 바로가기 DB 부;

   입력 구문을 상기 검색어 추천 DB와 상기 검색룰 추천 DB에 기초하여 검색어와 검색룰의 입력을 돕는 질의어 추천 모듈;

   질의어를 상기 개인 설정 정보 DB와 상기 검색창 정보 DB에 기초하여 요소별로 분류하고 복원하는 설정 정보 복원 모듈;

   상기 분류되고 복원된 질의어가 명령어인지 파악하고 해당 명령어를 수행하도록 메시지를 구성하는 명령어 분석 모듈;

   상기 검색룰 정보 DB와 상기 바로가기 DB에 기초하여 상기 설정 정보 복원 모듈 또는 상기 명령어 분석 모듈을 거쳐 분류되고 복원된 질의어를 메시지로 변환하는 메시지 복원 모듈;

   상기 메시지 복원 모듈 또는 상기 명령어 분석 모듈로부터 생성된 메시지를 이용자에게 리디렉션 방식으로 돌려주는 리디렉션 모듈;

   상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 템플릿 방식으로 돌려주는 템플릿 모듈;

   상기 메시지 복원 모듈에서 생성된 메시지를 이용자에게 프락시 방식으로 돌려주는 프락시 모듈

   을 포함하는 것을 특징으로 하는 검색창 서비스 시스템.
2. 제 1항에 있어서,

   상기 개인 설정 정보 DB에는, 기본 구분자가 ‘at’으로 등록되어 있고 이용자의 선택에 따라 ‘>>’등의 기호나 ‘앳' 등의 문자를 등록할 수 있는 것을 특징으로 하는 검색창 서비스 시스템.
3. 제 1항에 있어서,

   상기 질의어 추천 모듈은, 상기 검색어 또는 검색룰 추천 단계에 있어서 스폰서가 있는 검색어 또는 검색룰을 추천 영역의 상단에 표시하여 이용자의 선택을 유도하고, 이용자 선택 시 스폰서별로 선택 횟수를 상기 검색어 추천 DB 또는 상기 검색룰 추천 DB에 저장하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 시스템.
4. 이용자로부터 질의어를 입력받는 입력 단계;

   완성된 질의어를 상기 개인 설정 정보 DB와 상기 검색창 정보 DB에 기초하여 요소별로 분류하고 복원하는 설정 정보 복원 단계;

   상기 검색룰 정보 DB에 기초하여 분류되고 복원된 질의어를 메시지로 복원하는 메시지 복원 단계;

   복원된 메시지를 이용자에게 돌려주는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
5. 제 4항에 있어서,

   상기 입력 단계는, 이용자가 입력한 구문과 관련하여 검색어 추천 DB가 추천한 검색어를 선택하는 경우 또는 입력 구문이 검색어만으로 이루어진 경우 상기 검색룰 추천 DB에 기초하여 구분자를 포함한 검색룰이 추천되면, 추천되는 검색룰 중 상기 개인 설정 정보 DB에 등록된 기본 검색룰을 선택하면 기본 검색룰을 입력하는 단계;

   추천하는 검색룰 중 상기 개인 설정 정보 DB에 등록된 채택룰을 선택하면 해당 채택룰을 입력하는 단계;

   추천하는 검색룰 중 기본 검색룰 또는 채택룰이 아닌 검색룰을 선택하면 상기 개인 설정 정보 DB에 등록된 선택 기준에 부합하는 검색룰을 입력하는 단계; 및

   추천하는 검색룰 중 어느 검색룰도 선택하지 않으면 기본 검색룰을 입력하는 단계를 거쳐 완성된 질의어를 입력받는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
6. 제 4항에 있어서,

   상기 설정 정보 복원 단계는, 상기 복원된 질의어에 명령어가 포함되어 있으면 명령어 분석을 통하여 바로가기 명령어인 경우 상기 바로가기 DB에 기초하여 바로가기 명령을 실행하는 단계;

   바로가기 이외의 명령어인 경우 해당 명령어를 실행하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
7. 제 4항 또는 제 5항에 있어서,

   상기 설정 정보 복원 단계는, 상기 복원된 질의어에 구분자가 없고 검색창에 상기 검색창 정보 DB에 설정된 기본 검색룰이 있다면 기본 검색룰을 선택하는 단계;

   상기 복원된 질의어에 구분자가 없고 검색창에 기본 검색룰이 없다면 상기 개인 설정 정보 DB에 설정된 이용자 기본 검색룰을 선택하는 단계;

   상기 복원된 질의어에 구분자가 없고 검색창에 기본 검색룰이 없으며 상기 개인 설정 정보 DB에 설정된 이용자 기본 검색룰이 없다면 글로벌 기본 검색룰을 선택하는 단계;

   상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있지 않으면 신규 검색룰을 등록하는 페이지로 URL을 지정하여 메시지를 복원하는 메시지 복원 단계;

   상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있으며 이용자가 해당 검색룰을 채택하여 상기 개인 설정 정보 DB에 저장되어있다면 이용자가 채택한 검색룰을 선택하는 단계;

   상기 복원된 질의어에 구분자가 포함되어 있고 구분자 다음에 위치한 검색룰이 상기 검색룰 정보 DB에 등록되어 있으며 이용자가 채택하지 않았다면 상기 개인 설정 정보 DB에 저장되어 있는 검색룰 선택 기준에 기초하여 검색룰을 선택하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
8. 제 7항에 있어서,

   상기 복원된 메시지를 이용자에게 돌려주는 단계는, 서비스 서버로 상기 검색창 서비스 시스템이 검색어를 전송한 후 결과를 받아서 재구성하여 이용자의 화면에 전송하는 프락시 방식으로 하는 단계;

   템플릿을 생성해 전송하고 이용자의 컴퓨터가 서비스 서버로부터 직접 결과를 받아와서 이용자의 화면에 표시하는 템플릿 방식으로 하는 단계;

   검색룰에 따라 URL을 복원하여 이용자 화면에 표시하는 리디렉션 방식으로 하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
9. 제 4항 또는 제 6항에 있어서,

   상기 메시지 복원 단계는, 상기 개인 설정 정보 DB에 기초하여 URL 중 서버 주소 부분을 IP 주소로 치환하여 보내는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.

Images