KR20080030796A - 검색창 서비스 시스템 및 제공 방법 - Google Patents

Abstract

본 발명은, 사용자로부터 입력 구문을 입력받는 입력 단계, 입력된 상기 입력 구문을 상기 구문에 포함된 구분자와 공백을 기준으로 배열화하여 적어도 하나의 배열 변수에 저장하는 배열 단계; 사용자 각각 약어를 등록해 저장하는 사용자 정보 DB, 및 사이트의 약어 및 URL을 저장하는 URL DB를 기초하여 상기 배열 변수로부터 사용자 약어 및 공통 약어를 복원하여 적어도 하나의 복원 변수를 저장하는 복원 단계; 상기 URL DB를 기초하여 상기 복원 변수를 각각의 분류별로 처리방법이 지정된 적어도 하나의 요소로 각각 분류하는 분류단계; 및 상기 URL DB 또는 상기 구문 DB를 기초하여 상기 요소로부터 리디렉션 메시지를 생성하는 단계를 포함한다.

검색창, 리디렉션, 검색엔진

Description

검색창 서비스 시스템 및 제공 방법{SEARCH BOX SERVICE SYSTEM AND METHOD OF OPERATION THEREOF}

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

도 2는 본 발명에 따른 검색창 서비스 시스템에서의 주소창 입력 구문의 처리 방법도.

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

도 4는 본 발명에 따른 검색창 서비스 시스템의 검색창 서비스 실시예 설명도.

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

300 : 검색창 서비스 시스템 301 : 사용자 정보 DB

302 : 검색 엔진 DB 303 : 바로 가기 DB

304 : 어플리케이션 DB 305 : 구문 DB

311 : 배열화 모듈 312 : 사용자 약어 복원 모듈

313 : 공통 약어 복원 모듈 314 : 요소 분류 모듈

315 : 리디렉션 메시지 생성 모듈

본 발명은 검색창 서비스 시스템 및 제공 방법에 관한 것으로, 더욱 상세하게는 검색 엔진 지정 검색, 검색 엔진 기반 바로 가기, 검색창 기반의 커뮤니케이션 및 검색창 기반의 부가 서비스 시스템 및 제공 방법에 관한 것이다.

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

또한 아마존(Amazon)에서 상품을 찾으려고 할 때에도 아마존이라는 사이트에 가서 검색을 하는 것이 효율적이나, 종래의 검색엔진의 회사와 아마존의 제휴가 있지 않은 이상 불가능한 것이다. 만약 제휴를 했다고 해도 검색엔진이 중간에서 아마존으로 사용자의 요청을 재전송하고 처리결과를 받아 편집해서 보여줄 경우 사용자 요청이 많아질수록 검색엔진의 처리 용량이 늘어나게 되는 문제가 있고, 기본적으로 제휴에 의한 제공은 제휴가 늘어날수록 시스템 간의 연동이 필요하게 되어 유연성이 떨어지게 된다. 반면에 본 발명에서 제공하는 검색창에 의한 방법은 클라이언트와 서비스 서버의 중간에 위치하는 검색창 서비스 시스템의 부하가 크지 않고 시스템 간의 연동이 필요 없으며 유연성이 높아 매우 다양하게 활용될 수 있다.

현재 검색 포털들은 다양한 기능을 제공하는 검색툴바(Search Toolbar)를 제공하여 검색의 주도권을 잡으려고 경쟁하고 있으나 주소창 검색과 인스턴트 검색창에 의해 검색툴바의 영향력이 크게 감소할 것으로 예상된다.

자체 검색 엔진은 물론 타사의 검색엔진까지도 편리하게 이용할 수 있는 방안이 요구되며, 검색엔진의 기능뿐만 아니라 바로 가기, 커뮤니케이션 및 인스턴트 메세징 기능 등과 같은 다양한 부가 기능을 제공하는 것이 요구된다.

본 발명은 상기와 같은 문제점을 해결하기 위해 고안된 것으로 사용자의 입력 구문을 상기 검색창 서비스 시스템을 통하여 입력 구문에 맞는 검색 엔진 또는 어플리케이션 서버의 URL(Uniform Resource Locator)로 변환하여 리디렉션(Redirection) 메시지로 제공함으로써 효과적으로 검색창 기반의 다양한 서비스를 제공하는 것이 필요하다.

상술한 목적을 달성하기 위한 본 발명은, 사용자 각각 약어를 등록해 저장하는 사용자 정보 DB, 사이트의 약어 및 URL을 저장하는 URL DB, 및 브라우저 기반의 실행 구문을 저장하는 구문 DB를 포함하는 DB부; 입력 구문을 구분자와 공백을 기준으로 배열화하여 적어도 하나의 배열 변수에 저장하는 배열화 모듈;상기 사용자 정보 DB를 기초하여 상기 배열화 모듈의 상기 배열 변수로부터 사용자 약어를 복원하여 적어도 하나의 복원 변수를 저장하는 사용자 약어 복원 모듈; 상기 URL DB를 기초하여 상기 배열 변수들로부터 공통 약어를 복원하여 상기 복원 변수에 저장하 는 공통 약어 복원 모듈; 상기 URL DB를 기초하여 상기 복원 변수를 적어도 하나의 요소로 각각 분류하고 각각의 분류별로 처리방법을 지정하는 요소 분류 모듈; 및 상기 URL DB 또는 상기 구문 DB를 기초하여 상기 요소로부터 리디렉션 메시지를 생성하는 리디렉션 메시지 생성 모듈을 포함하는 것을 특징으로 한다.

본 발명의 검색창 서비스 시스템의 URL DB는, 검색 엔진별 약어 및 검색 엔 진 URL을 저장하는 검색 엔진 DB; 키워드 등록된 각각의 URL의 약어를 저장하는 바로 가기 DB; 및 어플리케이션 사이트의 URL을 저장하는 어플리케이션 DB를 포함할 수 있다.

또한, 본 발명에 따른 검색창 서비스 방법의 다른 실시형태는, 배열화 모듈을 이용하여 수신된 입력 구문을 배열화 하는 단계; 사용자 약어 복원 모듈을 이용하여 로그인한 가입자에 대해 사용자 약어를 복원하는 단계; 공통 약어 복원 모듈을 이용하여 공통 약어를 복원하는 단계; 요소 분류 모듈을 이용하여 구문을 분석하여 각각의 상황별로 처리방법을 지정하는 요소 분류 단계; 및 리디렉션 메시지 생성 모듈을 이용하여 DB조회를 통해 얻은 URL 템플릿에 입력 구문을 적용하여 리디렉션 메시지를 생성하는 단계를 포함할 수 있다.

또한, 본 발명의 분류 단계는 구분자 및 배열화된 값을 체크하여, 구분자가 없으면 검색 엔진 DB에서 기본 지정된 검색 엔진 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값이 null이면 구분자 이전 값에 따라 바로 가기 DB에서 바로 가기 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값을 검색 엔진 DB에서 조회하여 세부 검색 관련 값이면 세부 검색의 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값을 검색 엔진 DB에서 조회하여 타 검색 엔진 관련 값이면 타 검색 엔진의 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값이 실행 명령어이면 어플리케이션 DB에서 실행 명령어 관련 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값이 전화번호, 메일주소 메신저주소 등이면 어플리케이션 DB에서 메시징을 위한 URL을 조회하는 단계; 구분자가 있고 구분자 다음 값이 상기에 해당 사항이 없고, 입력 구문 처음 값이 실행 명령어이면 어플리케이션 DB에서 실행 명령어 관련 URL을 조회하는 단계; 및 입력 구문 마지막 값에 새 창으로 띄우기, 새 탭으로 띄우기 등 구문 관련 명령이 있으면 구문 DB에서 구문을 조회하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명에 따르면, 입력 구문이‘문자열A 구분자 문자열B’,‘문자열 A 구분자’, ‘구분자 문자열A ’, ‘문자열A’중 어느 하나의 형태인 경우에 대하여 상기 요소 분류 단계를 수행하며, 구분자는 ‘>>’, ‘//’, ‘..’와 같은 기호가 사용된다.

또한, 본 발명은 상기 입력 구문이 ‘문자열A 구분자 문자열B’의 형태인 경우, 문자열A가 검색엔진, 문자열B가 검색어의 값을 갖거나 문자열A가 검색어, 문자열B가 검색엔진 값을 가지면 상기 요소 분류 단계에서 지정 검색 엔진으로 연결되는 것을 특징으로 한다.

또한, 본 발명은 상기 입력 구문이‘문자열A’의 형태인 경우, 문자열A가 검색어의 값을 가지면 상기 요소 분류 단계에서 기본 검색 엔진으로 연결되는 것을 특징으로 한다.

또한, 본 발명은 상기 입력 구문이 ‘문자열A 구분자’, ‘구분자 문자열A', ‘문자열A' 중 어느 하나의 형태인 경우, 상기 요소 분류 단계에서 바로 가기 기능을 수행하며, 기존의 바로 가기와 달리 문자열A가 공백을 포함하는 여러 개의 단어로 구성될 수 있으며, 그 중 ‘문자열A 구분자’는 '/'를 구분자로 써서 '문자열A /'나 ‘문자열A/'와 같은 형태도 포함하며, ‘문자열A’는 상기 브라우저의 주소창 을 통해 전달 받은 입력 구문이 다른 경로를 통해 전달 받은 동일한 입력 구문과 구분이 가능할 경우, 상기 브라우저의 주소창을 통해 전달 받은 입력 구문 ‘문자열A'에 대해, 상기 요소 분류 단계의 검색 엔진 DB에서 기본 지정된 검색 엔진 URL을 조회하는 단계에 앞서 바로 가기 DB에서 바로 가기 URL을 조회하는 단계를 먼저 수행하여 해당하는 값이 있으면 바로 가기로 처리한다.

또한, 본 발명은 상기 입력 구문이‘문자열A 구분자 문자열B'의 형태인 경우, 문자열A가 커뮤니케이션 내용을, 문자열B가 수신자 또는 송신자의 값을 갖거나 문자열A가 수신자 또는 송신자의 값을, 문자열B가 커뮤니케이션 내용을 가지면 상기 요소 분류 단계에서 SMS, 메일, 메신저, 인터넷 전화와 같은 커뮤니케이션 기능을 수행한다.

또한, 본 발명은 상기 입력 구문이‘문자열A 구분자 문자열B'의 형태인 경우, 문자열A, 문자열B 중 하나가 부가 기능과 관련된 실행 명령어를 포함하면 상기 요소 분류 단계에서 채팅, 태깅, 스크랩, 상세정보, 구매와 같은 부가 기능을 수행하는 것을 특징으로 한다.

또한, 본 발명은 상기 입력 구문이‘문자열A 구분자 문자열B'의 형태인 경우, 문자열B의 끝 부분에 해당 기능 수행을 위한 명령어를 추가할 수 있다면 상기 요소 분류 단계에서 새 창으로 띄우기, 새 탭으로 띄우기, 팝업으로 띄우기와 같은 클라이언트 기반의 명령을 수행하는 것을 특징으로 한다.

한편, 본 발명은 상기 검색창 서비스 시스템을 기존에 존재하는 검색 엔진 사이트나 서비스 사이트와 별도의 사이트에 구현할 수 있다.

또한, 본 발명은 상기 검색창 서비스 시스템을 기존 검색 엔진 사이트에 통합하여 구현하는 것을 특징으로 하며, 기본 검색을 이용한 검색은 리디렉션을 하지 않고 직접 검색할 수 있다.

본 발명은 상기 검색창 서비스 시스템을 브라우저, 검색툴바, 운영체제에 통합하여 구현될 수 있다.

또한, 본 발명은 상기 검색창 서비스 시스템에 입력되는 구문이 상기 검색창 서비스 시스템이 구현된 서버의 홈페이지의 검색창, 브라우저의 주소창, 인스턴트 검색창, 검색툴바의 검색창, 외부에서 링크로 연결된 검색창, 운영체제의 검색창 중 어느 하나를 통해 입력되는 것을 특징으로 한다.

본 발명은 상기 검색창 서비스 시스템은 분석된 구문 결과를 내부 또는 외부 의 백업 DB에 보내어 입력 구문을 구분 관리함으로써 향후 인기 검색어 분석 등에 활용할 수 있는 것을 특징으로 한다.

이하, 도면을 참조하여, 본 발명의 구성과 작동 방법을 보다 상세하게 설명한다.

도 1은 검색창 서비스 시스템(300)의 구조를 나타낸다. 검색창 서비스 시스템(300)은 검색창에 입력된 입력 구문을 분석하여 서비스에 부합하는 서비스 URL을 만들어 서비스 서버로 리디렉션 하는 역할을 수행한다. 이를 위해 입력 구문은 배열화 모듈(311), 사용자 약어 복원 모듈(312), 공통 약어 복원 모듈(313), 요소 분류 모듈(314), 리디렉션 메시지 생성 모듈(315)을 거치게 되며, 그 과정에서 각 모듈은 필요에 따라 사용자 정보 DB(301), 검색 엔진 DB(302), 바로 가기 DB(303), 어플리케이션 DB(304), 구문 DB(305)를 참조하게 된다.

이해를 돕기 위해 예제를 들어 간략하게 설명하면, 검색창에 ‘wine cellar >> auction'이라는 입력 구문이 들어왔다고 가정하자. 이 입력 구문은 www.auction.co.kr 을 통해 wine cellar 상품을 검색하라는 의미이다.

먼저, 배열화 모듈(311)은 구분자와 공백에 따라 해당 입력 구문을 요소별로 분류하게 되는데 이에 따라 입력 구문은 before[0]=wine, before[1]=cellar, after[0]=auction으로 배열화되어 정리되게 된다. 사용자 약어 복원 모듈(312)은 이 예제에서는 해당하는 것이 없고, 그 다음 단계인 공통 약어 복원 모듈(313)에 의해 after[0]=auction은 after[0]=search.auction.co.kr로 복원되게 된다. 이때 www.auction.co.kr로 변환되지 않은 이유는 실제 검색은 www.auction.co.kr이 아닌 search.auction.co.kr에서 이루어지기 때문이다. 그 다음 단계인 요소 분류 모듈(314)에서는 검색 엔진 DB(302)의 구문을 참조하여 search.auction.co.kr이 keyword라는 값을 필요로 함을 알아내어 before[0]=wine과 before[1]=cellar를 합쳐서 keyword=wine+cellar로 만들어낸다. 최종단계인 리디렉션 메시지 생성 모듈(315)은 ‘search.acution.co.kr/search/search.aspx?keyword=wine+cellar'라는 URL을 갖는 리디렉션 메시지를 완성하여 클라이언트에게 전송하게 된다.

다음으로 검색창에 ‘call >> tom'이라는 입력 문구가 입력되었다고 하자. 이 입력 문구는 tom에게 인터넷 전화를 걸라는 의미이다. 하지만 tom에 대한 인터넷 전화번호를 알 수 없기 때문에 사용자가 사전에 tom의 전화번호는 070-5678-1234라로 등록해 두었고 현재 로그인을 한 상태라고 가정하기로 하자.

먼저, 배열화 모듈(311)은 구분자와 공백에 따라 해당 입력 구문을 요소별로 분류하게 되는데 이에 따라 입력 구문은 before[0]=call, after[0]=tom으로 배열화되어 정리되게 된다. 다음으로 사용자 약어 복원 모듈(312)은 tom의 연락처를 070-5678-1234로 변환하게 되어 after[0]=07056781234로 변경되게 된다. 그 다음 단계인 공통 약어 복원 모듈(313)에 의해 before[0]=call은 before[0]=www.freevoip.com으로 복원되게 된다. 이때 www.freevoip.com은 예제로 든 가상의 인터넷 전화 서버이다. 요소 분류 모듈(314)에서는 검색 엔진 DB(302)의 구문을 참조하여 www.freevoip.com이 callee라는 값을 필요로 함을 알아내어 callee=07056781234를 만들어낸다. 최종단계인 리디렉션 메시지 생성 모듈(315)은 ‘www.freevoip.com/call.aspx?callee=07056781234'라는 URL을 갖는 리디렉션 메시지를 완성하여 클라이언트에게 전송하게 된다.

각각의 구성 요소에 대해 좀 더 자세히 살펴보면, 배열화 모듈(311)은 구분자를 기준으로 구분자의 앞부분을 before[i]라는 배열 변수에 뒷부분을 after[i]라는 배열 변수에 저장하게 된다. 상기 예제에서는 ‘>>’를 구분자로 사용하였지만 ‘//’, ‘..’, ‘<<’ 등 다양한 것들이 구분자로 사용될 수 있다. 또한, at과 같은 전치사를 이용하여 자연어에 보다 가깝게 표현할 수도 있는데 이 경우 'wine cellar at auction'과 같은 방법으로 표현될 수 있다. 또한, 앞에 사이트 주소를 놓고 뒤에 검색어를 두는 것도 가능한데 이 경우 ‘auction << wine cellar'과 같은 방법으로 표현될 수 있다.

사용자 약어 복원 모듈(312)은 사용자가 미리 등록해 놓은 약어를 복원하는 모듈로서 사용자가 로그인을 한 상태에서 사용이 가능하다. 이 때 등록할 수 있는 사용자 약어는 전화번호, 메일 주소와 같은 경우에 한정하는 것이 바람직하다. 너무 많은 사용자 약어를 사용할 경우 명령어와 혼동이 될 수도 있다.

공통 약어 복원 모듈(313)은 공통적으로 사용되는 약어들을 복원하는 모듈이다. 앞서 예를 든 바와 같이 auction은 search.auction.co.kr로, call은 www.freevoip.com으로 복원하는 것과 같은 경우이다. 공통 약어는 일반적으로 검색 엔진이나 어플리케이션 서버에 적용될 수 있다.

요소 분류 모듈(314)은 검색 엔진이나 어플리케이션 서버에서 필요로 하는 변수별로 배열화된 입력 구문을 재구성하는 모듈이다. 앞서 예를 든 auction의 경우 keyword라는 변수를 필요로 해서 keyword=wine+cellar로, call의 경우 callee라 는 변수를 필요로 해서 callee=07056781234로 만들어 준 것과 같다.

리디렉션 메시지 생성 모듈(315)은 앞의 변수들을 검색 엔진 DB(302)나 어플리케이션 DB(304)의 템플릿(template)에 넣어 리디렉션 URL을 생성한 후 클라이언트에게 리디렉션 하는 역할을 한다. 이때 리디렉션 방법으로는 HTTP(HyperText Transfer Protocol) 리디렉션 메시지를 이용하는 방법, 메타(Meta) 태그를 이용하는 방법, 자바 스크립트(Java Script)를 이용하는 방법 등이 고려될 수 있으며, 상기 입력 구문의 마지막에 ‘tap', 'window', 'popup' 등이 있었다면 구문 DB(305)를 조회하여 새 탭으로 열기, 새 창으로 열기, 팝업으로 열기 등에 맞는 형태로 리디렉션 메시지를 구성하여 클라이언트에게 보내줄 수 있다.

사용자 정보 DB(301)는 사용자별 저장 정보를 저장해 두는 곳으로서 일반적으로 SMS, 메일, 메시지, 인터넷 전화와 같은 서비스를 이용할 때 입력해야 하는 수신자 주소를 간편하게 입력하기 위하여 사용될 수 있다. 사용자 정보 DB(301)를 이용하기 위해서는 ID와 패스워드를 이용한 로그인이 필요하며 로그인한 사용자가 상기의 기능을 이용할 때에는 송신자를 따로 지정해 주지 않아도 된다. 수신자, 송신자 지정 이외에도 사용자별로 기본 검색 엔진을 지정하거나, 검색 엔진이나 서비 스 별로 자신만의 약어를 만들어 이용하는 것도 가능하지만 이 경우 혼동이 있을 수 있으므로 주의가 필요하다. 또한 스크랩(scrap)과 같은 서비스를 이용할 때도 이용 가능하다.

검색 엔진 DB(302)는 검색 엔진 별로 영어 약어, 한글 약어, 사이트 주소, 검색 엔진의 주소 및 검색 엔진에서 필요로 하는 URL 템플릿을 저장해 두는 곳으로서 예를 들어 (auction, 옥션, www.auction.co.kr, search.auction.co.kr, search/search.aspx?keyword=)와 같은 정보를 묶어서 관리함으로써 ‘wine cellar >> auction'과 같은 입력을 ‘search.acution.co.kr/search/search.aspx?keyword=wine+cellar'라는 URL로 변경시키는 과정에 이용된다.

바로 가기 DB(303)는 등록된 키워드에 대해 바로 가기를 수행하기 위한 모듈로서 기존의 바로 가기와 달리 두 단어 이상의 키워드도 지원되도록 설계된다. 특히 한글, 일본어와 달리 띄어쓰기가 중요한 영어의 경우 이러한 두 단어 이상의 키워드 지원 기능이 유용하게 이용될 수 있다.

어플리케이션 DB(304)는 어플리케이션 별로 영어 약어, 한글 약어, 사이트 주소, 어플리케이션 서버 주소 및 어플리케이션 서버에서 필요로 하는 URL 템플릿을 저장해 두는 곳으로서 예를 들어 (call, 전화, www.freevoip.com, www.freevoip.com, call.aspx?callee=)과 같은 정보를 묶어서 관리함으로써 ‘call >> 07056781234’와 같은 입력 구문을 ‘www.freevoip.com/call.aspx?callee=07056781234'라는 URL로 변경시키는 과정에 이용된다.

구문 DB(305)는 새 창으로 열기, 팝업으로 열기, 새 탭으로 열기는 물론 클라이언트에서 실행될 수 있는 명령어를 지원하기 위한 구문을 담고 있는 DB이다. 예를 들어 ‘cellar >> dic tap'라는 입력 구문이 ‘cellar라는 단어를 사전 검색을 해서 새로운 탭에 열어라’라는 의미라고 하면 새로운 탭에 열기 위한 HTML 또는 자바스크립트와 같은 구문을 구문 DB(305)를 통해 가져올 수 있다. 물론 현재는 새 탭으로 열기라는 HTML 또는 자바스크립트 구문이 없는 것으로 알고 있지만 탭 브라우징의 활성화로 곧 생기게 될 것으로 예상된다.

도 2는 클라이언트(100)가 브라우저의 주소창을 통한 입력이 검색창 서비스 시스템(300)으로 전달되어 원하는 서비스 서버(500)로 리디렉션되는 경우를 나타낸 다. 현재 베타 테스트를 진행하고 있는 IE7의 경우 주소창 입력 구문에 대해 DNS(Domanin Name Service) 서버(200)로 메시지를 보내어 입력 구문이 올바른 주소인지 확인하고, 올바른 주소가 아닌 경우 기본 검색 엔진으로 입력 구문을 전달하도록 설계되어 있다. 이 경우 기본 검색 엔진으로 이용자가 원하는 검색 엔진을 설정할 수 있는데 만약에 상기 검색창 서비스 시스템(300)이 기본 검색 엔진으로 지정되어 있을 경우에는 검색창 서비스 시스템(300)에서 입력 구문을 분석하여 적절한 서비스 서버(500)로 접속할 수 있도록 리디렉션 메시지를 보내게 된다. 또한 이 과정에서 분석된 입력 구문을 내부 또는 외부에 있는 백업 DB(400)에 저장 해 둠으로써 향후에 인기 검색어 통계 등에 활용할 수 있게 된다. 만약 브라우저의 인스턴트 검색창이나 홈페이지의 검색창을 이용한다면 도 2의 1번(DNS 서버 요청)과 2번(DNS 서버 응답) 과정이 없이 바로 3번(지정된 기본 검색 엔진으로 입력값 전달) 과정부터 진행이 될 것이다.

브라우저 파이어폭스의 기본 설정은 IE7과 달리 주소창 입력 구문에 대한 DNS 확인 절차 이후에 올바른 주소가 아닌 경우, 구글의 ‘운 좋은 예감’ 서비스로 입력 구문을 전달하여 바로 가기를 수행하게 되어 있고, IE7과 달리 손쉽게 기 본 검색 엔진을 수정하기 어렵게 되어있지만, ‘about:config'를 주소창에 입력한 후 설정 변경을 통해 구글의 ‘운 좋은 예감’외에 다른 검색 엔진으로 기본 검색 엔진을 지정할 수 있다.

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

또한 상기 검색창 서비스 시스템(300)은 기존의 검색 엔진 사이트나 서비스 사이트와 별도의 사이트에 구현될 수도 있지만 기존 검색 엔진 사이트에 통합하여 구현될 수도 있다. 만약 A라는 검색 엔진에 상기 검색창 서비스 시스템(300)이 통합 구현될 경우 기본적인 검색은 A에서 처리하기 때문에 리디렉션 과정이 필요 없어지며, 세부 검색이나 다른 검색 엔진을 이용한 검색, 커뮤니케이션이나 부가 기 능을 이용하는 경우에는 리디렉션 메시지를 이용하여 클라이언트(100)가 다른 서비스 서버(500)를 이용할 수 있게 된다.

또 다른 방법으로는 IE7, 파이어폭스와 같은 브라우저에 상기 검색창 서비스 시스템(300)의 기능을 구현하는 방법이나 야후, 네이버와 같은 서비스 사이트에서 제공하는 검색툴바의 검색창 또는 새로 출시될 윈도우 비스타와 같은 운영체제의 검색창에 상기 검색창 서비스 시스템(300)의 기능을 구현하는 방법을 생각할 수 있는데 이러한 경우에도 클라이언트(100) 자체만으로는 이러한 기능을 수행하기 어렵기 때문에 상기 검색창 서비스 시스템(300)과 같은 역할을 하는 서버가 존재해야 할 것이다.

도 3은 검색창 서비스 시스템의 처리 순서도를 나타낸다. 먼저 배열화 모듈을 통해 다양한 경로로 수신된 입력 구문을 배열화(10)한 후 사용자 약어 복원 모듈을 통해 사용자 약어를 복원(20)하고, 공통 약어 복원 모듈을 통해 공통 약어를 복원(30)하는 과정이 이루어진다. 그 다음으로는 요소 분류 모듈이 수행되는데 요소 분류 모델은 먼저 구분자가 존재하는 지를 먼저 파악하게 된다(40). 구분자가 없을 경우 일반적인 검색을 위한 입력이기 때문에 기본 검색엔진 URL을 조회하게 된다(41).

구분자가 존재하고 배열화된 입력 구문(42) 중 after[0]값이 없을 경우에는 바로 가기를 의미하기 때문에 바로 가기 DB를 조회하여 바로 가기 URL을 가져오게 된다(43). 만약 after[0]값이 dic.naver.com, news.naver.com, blog.naver.com과 같이 통합 검색이 아닌 세부 검색일 경우에는 검색 엔진 DB에서 세부 검색 엔진의 URL과 템플릿을 가져오게 된다(44).

after[0]이 www.empas.com, www.auction.co.kr과 같이 타 검색 엔진일 경우에는 역시 검색 엔진 DB를 조회하여 타 검색 엔진의 URL과 템플릿을 가져오게 되고(45), after[0]이 chat, tag, scrap, info, buy 등과 같은 명령어일 경우 어플리케이션 DB에서 어플리케이션 서버의 URL과 템플릿을 가져오게 된다(46).

after[0]이 전화번호, 메일 주소, 메신저 주소와 같은 커뮤니케이션 명령어일 경우에는 역시 SMS 전송 서버, 인터넷 전화 서버, 메일 주소 서버, 메신저 서버 주소의 URL과 템플릿을 가져오게 된다(47). 이 때 after[0]이 전화 번호일 경우에는 before[0]의 값이 값을 조사(48)하여 call과 같은 명령어라면 인터넷 전화 서버 주소와 템플릿을 가져오게 되고(49), 그렇지 않다면 SMS 전송 서버의 주소와 템 플릿을 가져오게 된다(47).

다음으로 입력 구문의 마지막 값인 after[end]의 값을 조사하여(50) tap, window, popup 등의 명령어가 있다면 구문 DB를 조회(60)하여 새 탭으로 열기, 새 창으로 열기, 팝업으로 열기 등에 해당하는 구문 템플릿을 가져오게 된다.

마지막으로 가져온 URL과 템플릿 별로 배열화된 입력 구문을 맵핑시킴으로써 리디렉션 메시지가 완성되게 되고 이 메시지를 클라이언트에 전송함으로써 리디렉션이 이루어지게 된다(70).

여기에서 한 가지 주의할 것은 도 3에 나타나지는 않았지만 구분자가 존재하지 않을 경우, 수신된 입력 구문이 브라우저의 주소창을 통해 수신되었고, 그 사실을 검색창 서비스 시스템이 알 수 있다고 가정하면, 그러한 입력 구문에 대해서는 구분자가 없는 경우에도 검색 엔진 DB에서 기본 검색 엔진 URL을 조회하기 전에 바로 가기 DB에서 바로 가기 URL을 조회하여 바로 가기 기능이 수행 가능한지를 먼저 체크하게 된다. 이는 브라우저 주소창 입력에 대해서는 구분자가 없더라도 매칭되는 바로 가기가 있으면 바로 가기를 제공하고 바로 가기가 없는 경우에 검색 결과를 제공하는 것이 합리적이기 때문이다.

도 4는 검색창 서비스 시스템에서의 검색창 서비스 예제를 나타낸다. 먼저 첫 번째 예제인 ‘wine cellar’라는 입력 구문은 기본 검색엔진에서 wine cellar를 검색하라는 것이다. 구분자가 없이 입력되었기 때문에 기본 검색엔진에서 검색이 이루어지지만 전술한 바와 같이 브라우저의 주소창을 통해 입력되었다면 검색 엔진 DB를 조회하기에 앞서 바로 가기 DB를 조회하여 'wine cellar'와 연결된 사이트가 있다면 해당 사이트의 URL을 가져와 리디렉션 메시지를 생성하게 된다. 만약 바로 가기 DB에 'wine cellar'와 연결된 사이트가 없다면 원래대로 검색 엔진 DB를 검색하여 기본 검색 엔진의 URL과 템플릿을 이용하여 템플릿에 ‘wine cellar’를 넣어 리디렉션 메시지를 생성하게 된다.

두 번째 예제인 ‘cellar >> dic tap’은 'cellar'라는 단어를 dic.naver.com을 이용하여 검색한 후 그 결과를 새 탭에 표시하라는 의미이다. 물론 dic.naver.com을 이용한다는 것은 www.naver.com이 기본 검색 엔진으로 지정되었을 경우 dic.naver.com이 기본 검색 엔진의 사전 검색이기 때문이다. 만약 www.daum.net이 기본 검색 엔진으로 지정되었다면 dic.daum.net을 을 이용하여 사전 검색을 수행하게 된다. 한 가지 주의할 것은 검색 엔진에 따라서는 세부 검색을 수행함에 있어 별도의 세부 검색 엔진을 이용하지 않고 기본 검색 엔진의 입력 변수를 바꾸어서 수행하는 경우가 있는데 이 경우에는 리디렉션 메시지를 생성할 필요가 없이 검색 결과를 그대로 보내주면 될 것이다.

입력 구문 마지막의 tap은 새 탭으로 열라는 의미로 현재 브라우저에서는 지원이 되지 않는다. 하지만 새 창으로 열기, 팝업으로 열기가 HTML 또는 자바스크립트에서 지원이 되기 때문에 새 탭으로 열기도 곧 지원이 될 것으로 예상되며 이러한 구문과 관련된 템플릿은 구문 DB에서 가져오게 된다.

세 번째 예제인 ‘wine cellar >> auction’은 auction에서 wine cellar 상품을 검색하라는 의미이다. 이 때 공통 약어 복원 모듈과 요소 분류 모듈은 검색 엔진 DB를 조회하여 auction에 대한 URL과 템플릿을 가져오게 된다. 이러한 검색 엔진 DB의 약어와 사이트 주소의 맵핑은 수동적으로 이루어지지만 사이트 주소와 검색 엔진 URL 및 템플릿과의 맵핑은 자동화가 가능하다. 즉 auction과 맵핑될 수 있는 것은 www.auction.co.kr 뿐 아니라 www.auction.com도 가능하며 그 외에 auction이라는 이름을 포함하는 여러 사이트가 가능하기 때문에 수동적으로 맵핑을 해주어야 하지만 www.auction.co.kr과 search.auction.co.kr/search/search.aspx?keyword= 간의 맵핑은 www.auction.co.kr의 HTML(HyperText Markup Language) 코드를 분석하면 어느 정도 자동화가 가능하기 때문이다. 이러한 타사 검색 엔진에는 기존 검색 엔진 전문 사이트 뿐 아니라 예제에서와 같은 쇼핑몰 사이트, 웹하드 사이트, P2P 사이트 등에까지 폭 넓게 적용할 수 있어 그 활용 범위가 매우 넓다고 할 수 있다.

타사 검색 엔진을 이용할 경우 약어를 쓸 수도 있지만 사이트 이름을 그대로 입력해 주는 것도 가능하다. 예를 들어 ‘wine cellar >> www.auction.co.kr'과 같은 입력 구문은 'wine cellar >> auction'과 똑같이 처리될 것이다. 또한 브라우저의 인스턴트 검색창을 통한 데스크탑 검색이 지원된다면 ‘cellar >> desktop'과 같은 형태의 입력 구문으로 데스크탑 검색을 수행할 수 있을 것이다.

네 번째 예제인 ‘국민은행 >>’은 국민은행으로 바로 가라는 의미이다. 기존에 국내에서 바로 가기를 제공하는 방법으로는 DNS 서버를 이용하는 방법과 컴퓨터에 에이전트를 설치하여 브라우저 주소창의 입력을 가로채서 수행하는 방법이 있었다. 본 발명과 전자의 차이점은 본 발명은 DNS 서버 대신 검색창 서비스 시스템 또는 검색창 서비스 시스템이 구현된 검색 엔진을 이용하기 때문에 다양한 기능을 부가할 수 있다는 점이고 후자와의 차이점은 컴퓨터에 따로 에이전트를 설치할 필요가 없다는 것이다. 검색 엔진 기반으로 바로 가기를 제공하는 기존 방법으로는 구글의 ‘운 좋은 예감’이 있지만 ‘운 좋은 예감’의 경우 국민은행과 같은 고유 명사의 경우에는 국민은행을 찾아가기 때문에 문제가 없지만 ‘은행’이라는 보통 명사의 경우에도 사람들이 가장 많이 사용하는 국민은행으로 가기 때문에 쏠림 현상이라는 형평성의 문제가 생길 수 있다. 본 발명은 키워드 등록 기반의 바로 가기를 제공할 수 있어 은행과 같은 일반 명사 키워드에 대해서는 키워드를 먼저 선점한 사업자나 사용자에게 제공함으로써 사업자나 사용자에게 광고 효과를 제공할 수 있다.

또한 국내와 달리 단어 간의 띄어쓰기가 중요한 영어권 문화에서 한단어가 아닌 여러 단어 기반의 바로 가기를 제공할 수 있다는 점, 구분자를 넣지 않는 경우 주소창에서의 입력에 국한하여 바로 가기를 제공함으로써 이용자의 혼란을 막을 수 있다는 점 등을 특징으로 한다.

앞서 구분자의 예로써 ‘>>’를 이용하였지만 바로 가기의 경우에는 ‘국민은행 >>’을 입력하기 위해서는 공백을 입력하고 쉬프트 키를 눌러줘야 하는 어려 움이 있기 때문에 ‘국민은행/’과 같은 방법으로 좀 더 쉽게 바로 가기를 이용하게 할 수 있다. 실제 IE7에서 ‘국민은행>’, ‘국민은행.’, ‘국민은행,’ 등을 입력하게 되면 오류 메시지를 내지만 ‘국민은행/’은 오류 메시지를 내지 않기 때문이다. ‘국민은행/’은 파이어폭스에서도 물론 이용될 수 있다.

다섯 번째 예제인 ‘점심 같이 먹자 >> 01012345678 01056781234’는 01012345678에게 ‘점심 같이 먹자’는 SMS를 보내되 송신자를 01056781234로 해서 보내라는 의미이다. 물론 송신자 정보는 생략될 수 있다. SMS의 원가가 국내의 경우 10원 정도라는 점과 국내 메이저 포탈 첫 화면의 광고비의 합 역시 10원 정도라는 점을 감안하면 광고 기반의 SMS를 제공하는 것이 가능함을 알 수 있다. 또한 SMS 메시지의 마지막 부분에 광고주의 이름을 넣고 SMS 발신자 번호를 광고주의 연락처로 넣는 SMS 꼬리 광고 또는 메시지의 문맥에 맞춘 문맥 광고를 전송 완료 페이지에 제공하는 방법 등 다양한 수익 모델을 생각할 수 있다.

만약 로그인을 해서 송신하는 경우에는 사용자 정보 DB에 입력된 사용자 정보가 있기 때문에 송신자의 번호를 따로 입력할 필요가 없고, 자주 보내는 사람을 등록해서 번호 대신 이름으로 보내는 것도 가능하다. 또한 수익 모델 측면에서도 광고 없이 포인트나 유료 기반으로 SMS를 보내는 것도 가능하게 된다.

여섯 번째 예제인 ‘http://blog.com/~jane >> tom@naver.com jane@yahoo.com’은 현재 URL을 tom@naver.com에게 보내되 송신자를 jane@yahoo.com으로 해서 보내라는 의미이다.

일곱 번째 예제인 ‘http://blog.com/~jane >> tom@msn jane@msn’은 MSN 메신저를 이용하는 jane이 역시 MSN 메신저를 이용하는 tom에게 현재 URL을 메신저를 통해 보내라는 의미이다.

여덟 번째 예제인 ‘call >> 07012345678’는 07012345678라는 번호로 인터넷 전화를 걸라는 의미이다. 여섯 번째, 일곱 번째, 여덟 번째 예제의 경우에는 다섯 번째 예제인 SMS 전송에서와 같이 로그인을 통해 송신자 자동입력, 친구 등록 등이 제공 가능하며, 광고, 포인트 또는 유료 기반의 수익 모델 역시 제공 가능하다.

아홉 번째 예제인 ‘http://blog.com/~jane >> chat’는 현재 URL을 함께 보고 있는 사람들과 채팅을 할 수 있도록 채팅 프로그램을 구동하라는 의미이다. 현재 나와 있는 URL 기반의 채팅 프로그램인 ‘Gabbly'와 같은 프로그램을 이용하면 URL 기반의 채팅을 원활하게 제공할 수 있다.

열 번째 예제인 ‘http://blog.com/~jane >> tag 와인 클래식’은 해당 URL에 대해 와인, 클래식으로 태깅하라는 의미이고, 열한 번째 예제인 ‘http://blog.com/~jane >> scrap’은 해당 URL을 스크랩하라는 의미인데 이러한 태깅과 스크랩은 현재 널리 이용되고 있는 딜리셔스(del.icio.us)와 같은 사이트와 연동하여 제공될 수 있다. 물론 scrap 기능을 이용하기 위해서는 로그인이 필요하다.

열두 번째 예제인 ‘http://blog.com/~jane >> info’는 해당 URL에 관한 자세한 정보를 표시하라는 의미인데 구글의 페이지랭크(PageRank)와 연동하여 제공이 가능하다. 이외에도 buy와 같은 명령어가 있을 수 있는데 buy를 통해 해당 URL의 콘텐츠를 구매하는 모듈과 연동이 가능하다.

이상으로 다양한 예제에 대해 살펴보았는데 이러한 입력 구문을 정리하면 ‘문자열A 구분자 문자열B', '문자열A 구분자’, '구분자 문자열A', ‘문자열A'와 같은 4가지 형태로 요약될 수 있다. 여기서 구분자는 ‘>>’, ‘//’, ‘..’와 같이 일반적으로 많이 쓰이지 않는 기호나 기호의 조합을 이용하게 되며 구분자와 문자 열 사이에는 공백이 있는 편이 좋지만 공백 없이 입력이 되어도 검색창 서비스 시스템에서 해석이 가능해야 한다.

본 발명은, 사용자가 IE7이나 파이어폭스와 같은 브라우저의 검색 엔진 설정을 바꿀 필요가 없이 다양한 검색 엔진 및 어플리케이션을 손쉽게 이용 가능한 검색창 서비스 시스템을 제공한다. 그리고 예전에는 사이트를 찾아가서 검색창에 입력하는 두 단계로 검색이 이루어지던 것이 주소창이나 인스턴트 검색창에 한 번에 입력하는 것만으로 다양한 서비스를 이용할 수 있게 되는 효과가 있다.

검색 엔진 사업자 측면에서는 IE7이나 파이어폭스의 기본 검색 엔진으로 지정됨으로써 이용자가 증가해 영향력이 커지면서 광고 효과가 증대되는 효과가 있고 백업 DB에 저장된 인기 검색어 통계 기능을 이용해 이용자들의 요구에 효과적으로 대처할 수 있게 된다. 또한 바로 가기 DB에의 등록 수입을 기대할 수 있으며 SMS나 메시지 전송을 통한 광고 수익도 기대할 수 있다.

Claims (6)

1. 사용자 각각 약어를 등록해 저장하는 사용자 정보 DB,

   사이트의 약어 및 URL을 저장하는 URL DB, 및

   브라우저 기반의 실행구문을 저장하는 구문 DB를 포함하는 DB 부;

   입력 구문을 구분자와 공백을 기준으로 배열화하여 적어도 하나의 배열 변수에 저장하는 배열화 모듈;

   상기 개인 정보 DB를 기초하여 상기 배열화 모듈의 상기 배열 변수로부터 사용자 약어를 복원하여 적어도 하나의 복원 변수에 저장하는 사용자 약어 복원 모듈;

   상기 URL DB를 기초하여 상기 배열 변수들로부터 공통 약어를 복원하여 상기 복원 변수에 저장하는 공통 약어 복원 모듈;

   상기 URL DB를 기초하여 상기 복원 변수를 적어도 하나의 요소로 각각 분류하고 각각의 분류별로 처리방법을 지정하는 요소 분류 모듈; 및

   상기 URL DB 또는 상기 구문 DB를 기초하여 상기 요소로부터 리디렉션 메시 지를 생성하는 리디렉션 메시지 생성 모듈을 포함하는 것을 특징으로 하는 검색창 서비스 시스템.
2. 제 1 항에 있어서,

   상기 URL DB는, 검색 엔진별 약어 및 검색 엔진 URL을 저장하는 검색 엔진

   키워도 등록된 각각의 URL의 약어를 저장하는 바로가기 DB; 및

   어플리케이션 사이트의 URL을 저장하는 어플리케이션 DB를 포함하는 것을 특징으로 하는 검색창 서비스 시스템.
3. 사용자로부터 입력 구문을 입력받는 입력 단계;

   입력된 상기 입력 구문을 상기 구문에 포함된 구분자와 공백을 기준으로 배열화하여 적어도 하나의 배열 변수에 저장하는 배열 단계;

   사용자 각각 약어를 등록해 저장하는 사용자 정보 DB; 및 사이트의 약어 및 URL을 저장하는 URL DB를 기초하여 상기 배열 변수로부터 사용자 약어 및 공통 약어를 복원하여 적어도 하나의 복원 변수에 저장하는 복원 단계;

   상기 URL DB를 기초하여 상기 복원 변수를 각각의 분류별로 처리방법이 지정된 적어도 하나의 요소로 각각 분류하는 분류 단계; 및

   상기 URL DB 또는 상기 구문 DB를 기초하여 상기 요소로부터 리디렉션 메시지를 생성하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
4. 제 3 항에 있어서,

   상기 URL DB는, 검색 엔진별 약어 및 검색 엔진 URL을 저장하는 검색 엔진DB;

   키워드 등록된 각각의 URL의 약어를 저장하는 바로 가기 DB; 및

   어플리케이션 사이트의 URL을 저장하는 어플리케이션 DB를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
5. 제 4 항에 있어서,

   상기 복원 단계는, 상기 배열 변수 내에 구분자가 없으면 상기 검색 엔진 DB에 저장된 상기 검색 엔진 URL을 조회하는 단계;

   상기 배열 변수 내에 구분자가 있고 상기 구분자 다음 값이 null 이면 상기 구분자 이전 값에 따라 상기 바로 가기 DB에서 상기 바로 가기 URL을 조회하는 단계;

   상기 배열 변수 내에 구분자가 있고 상기 구분자 다음 값을 상기 검색 엔진 DB에서 조회하여 세부 검색 관련 값이면 세부 검색의 URL을 조회하는 단계;

   상기 배열 변수 내에 구분자가 있고 상기 구분자 다음 값이 전화번호, 메일 주소, 또는 메신저주소이면 상기 어플리케이션 DB에서 메시징을 위한 URL을 조회하는 단계; 및

   상기 배열 변수 내에 구분자가 있고 상기 구분자 이전 값이 실행 명령어이면 상기 어플리케이션 DB에서 실행 명령어 관련 URL을 조회하는 단계를 포함하는 것을 특징으로 하는 검색창 서비스 제공 방법.
6. 제 3 항 내지 제 5 항에 있어서,

   상기 구분자는 '>>', '//', '..' 와 같은 기호를 사용하는 것을 특징으로 하는 검색창 서비스 제공 방법.

Images