KR101640034B1

KR101640034B1 - 도메인 트래픽 순위

Info

Publication number: KR101640034B1
Application number: KR1020117026092A
Authority: KR
Inventors: 레오나드 오렌타스; 마크 코스터스; 데이브 모스톤; 앤드류 심슨; 에두아르도 지메네즈; 알렉스 홀메스; 카르틱 시암선더; 스리니바스 선카라; 파니 파따푸
Original assignee: 베리사인 인코포레이티드
Priority date: 2009-04-07
Filing date: 2010-04-07
Publication date: 2016-07-15
Also published as: US20110087769A1; BRPI1014234A2; AU2010234484B2; RU2011144861A; BRPI1014178A2; JP2012523762A; WO2010118111A1; JP2012523625A; US8527658B2; US8521908B2; EP2417537A1; AU2010234491A1; CA2757834A1; US20150089056A1; CA2757832C; AU2010234484A1; US8909760B2; US20100257024A1; EP2417535A1; CN102549562A

Abstract

마침표에 의해 분리된 n 개의 라벨을 지니는 도메인 명칭을 리졸브하라는 요청을 권한 있는 명칭 서버에서 수신하는 단계를 포함하는 도메인 트래픽을 결정하기 위한 자동화 방법이다. 맨 왼쪽에 있는 라벨은 첫 번째 라벨이며 최고 순위 도메인은 n 번째 라벨이다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함한다면 도메인 명칭에 대한 www 히트 카운터 및/또는 www 요청 서버 카운터가 증가된다. 수신된 도메인 명칭이 단지 두 라벨만을 지닌다면 도메인 명칭에 대한 정확한 히트 카운터 및/또는 정확한 요청 서버 카운터가 증가된다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않으며 오직 두 개의 라벨만을 지닌 것도 아니라면 도메인 명칭에 대한 또 다른 히트 카운터 및/또는 또 다른 요청 서버 카운터가 증가된다.

Description

도메인 트래픽 순위{DOMAIN TRAFFIC RANKING}

인터넷 상에서 사용자 활동을 이해하는 것이 더욱 중요해지고 있고, 인터넷이 계속하여 팽창하기 때문에, 더 어려워지고 있다. 인터넷의 상업적 이용은 지난 10년동안 극적으로 팽창한 한 영역이며, 사용자 활동을 이해하고, 모니터하고 예측하는데 특히 관심을 갖는 영역이다. 인터넷의 상업적 이용에 관한 한 중요한 면은 광고이다. 광고주는 특정 내용을 광고하기 위해 적합한 웹 사이트 또는 도메인을 결정함에 있어 트래픽 순위와 같은 요인을 사용할 수 있다. 마찬가지로, 웹 사이트 소유자는 이들의 웹 사이트 상에 광고에 대해 적합한 요금을 정하기 위해 트래픽 순위를 사용할 수 있다. 당업자에게 알려진 바와 같이 인터넷 광고는 클릭당 광고료 지불(pay per click; PPC) 적용과 같은 특정 광고의 효과를 직접적으로 보여줄 수 있는 많은 서로 다른 형태를 적용하였다.

그러나 트래픽 순위는 여전히, 인터넷 기반구조 관리의 다른 면뿐만 아니라, 인터넷 광고의 중요한 면이다. 예를 들면, 인터넷 상에 활동적인 웹 사이트의 수가 늘어남에 따라, 서버 관리, 웹 개발, 광고 포커스 및 광고료와 같은 결정을 알려주기 위한 정확한 트래픽 레이팅에 대한 요구가 증가하였다. 그러나 전형적으로 트래픽 스코어를 계산하기 위해 사용자들 또는 웹 사이트의 트래픽을 모니터링하는 종래의 트래픽 모니터링 서비스의 능력에는 한계가 있다.

인터넷이 내재적으로 운영되는 방법들에 대한 설명은 인터넷 상에서 특정 웹 사이트들에 있어 트래픽을 효율적으로 모니터링하고 레이팅하는 것에 관계된 문제를 이해하는데 도움이 될 수 있다.

인터넷 상에 웹 사이트를 만드는 과정은 전형적으로 등록자가 등록처를 통해 특정 도메인 명칭을 등록하는 것으로 시작한다. 등록자는 전형적으로 "example.com"과 같은 도메인 명칭을 나타내는 개인이거나 기관이다. 등록자는 명칭 등록을 처리하기 위해 등록처에 연락한다. 등록처는 필요한 도메인 명칭 서비스(DNS) 정보를 레지스트리에 보낸다. 등록처는 레지스트리에 보내진 것 외에 추가의 고객 정보를 내포한 데이터베이스를 유지 관리할 수 있다.

레지스트리는 등록처로부터 DNS 정보를 수신하고, 이 정보를 중앙 데이터베이스에 삽입하고, 도메인 명칭들이 전 세계에 사용자들에 의해 발견될 수 있도록 정보를 인터넷 상에 전파시킨다.

일반적으로, DNS는 사람이 판독할 수 있는 도메인 명칭들을 인터넷을 통해 TCP/IP 통신을 설정하는데 필요한 인터넷 프로토콜(IP) 숫자들로 바꾸는 인터넷 기반구조의 부분이다. 즉, DNS는 인터넷 상에 컴퓨터들에 할당되는 "123.4.56.78"과 같은 숫자로 된 IP 어드레스들보다는, "www.example.com"같은 기억하기 쉬운 도메인 명칭들을 사용하여 사용자들이 웹 사이트들 및 다른 자원들을 참조할 수 있게 한다. 각각의 도메인 명칭은 점들에 의해 분리된 일련의 문자 스트링들(라벨들)로 구성된다.

도메인 명칭에서 맨 우측 라벨은 "최고 순위 도메인"(TLD)로서 알려져 있다. 공지된 TLD들의 예들은 ".com"; ".net"; ".org." 등이다. 각각의 TLD는 예를 들면 "www.example.com"에서 "example" 레벨과 같이 TLD의 바로 좌측에 열거된 두번째-레벨 도메인들을 지원한다. 각각의 두번째-레벨 도메인은 예를 들면 "www.example.com"에서 "www" 레벨과 같이, 두번째-레벨 도메인의 바로 좌측에 위치된 다수의 제 3 레벨 도메인들을 포함할 수 있다. 실질적으로 아무 제한이 없는 또 다른 레벨 도메인도 있을 수 있다. 예를 들면 추가적인 도메인 레벨을 가진 도메인은 "www.photos.example.com"일 수도 있을 것이다.

추가적인 비-도메인 정보는 도메인 명칭을 포함하는 URI(Uniform Resource Identifier) 구조에 포함될 수 있다. 예를 들면 "경로" 부분은 사선("/")에 의해 분리되는 일련의 세그먼트들(반드시 디렉토리들을 나타내는 것은 아닐지라도 개념적으로 이들과 유사하다)이다. 이 정보는 "www.example.com/blog"에서 "blog"와 같이 도메인 명칭의 바로 우측에 포함될 수 있고 특정한 콘텐트를 확인하여 전달하거나 특정 코드를 실행하기 위해 서버 또는 다른 수신 기기에 의해 사용될 수 있다.

비-도메인 정보의 다른 예들은 쿼리(query)들 및 프래그먼트들을 포함할 수 있는데, 이들의 상세는 당업자들이 알고 있는 것으로 여기에서는 상세히 다루지 않는다. 이 정보의 조합들은 사용자를 동일 페이지의 또 다른 부분에 혹은 동일 혹은 다른 도메인의 부분일 수 있는 또 다른 웹 페이지에 내비게이트하는 웹 페이지 하이퍼링크들에 포함될 수 있다.

관계된 도메인 명칭들, 및 콘텐트는 "www.example.com"; "www.blog.example.com"; "www.example.com/blog"; 또는 "blog.example.com" 등과 같이 각각이 다른 의미를 갖는 계층적, 혹은 네스트(nest)되는 방식으로 구성될 수 있다. 이러한 관계된 도메인들은 다양한 도메인 명칭들을 리졸브하는 실제 IP 어드레스에서 유사성들을 공유할 필요가 없다. 이에 관하여 도메인 명칭의 부분은 요망되는 한 특정한 서버를 의미할 수 있는데, 예를 들면 "mail.example.com" 및 www.example.com"은 동일한 두번째-레벨 도메인에 대해서, 다른 기능들을 가진 서로 다른 서버들에 리졸브할 수 있다.

인터넷의 상기 등록 및 구조적 특징은 DNS 분해(resolution) 프로세스를 사용함으로써 인터넷 상에서 특정한 자원들을 발견하기 위해 최종-사용자 애플리케이션들에 의해 사용된다. DNS 분해 프로세스의 면들을 이하 본원의 요지를 이해하는데 도움이 되도록 설명한다.

각각의 TLD를 동작시키는(TLD 내에 두번째-레벨 도메인들의 레지스트리를 유지 관리하는 것을 포함한) 임무는 한 특정한 도메인 명칭 레지스트리에 위임된다. 레지스트리는 이러한 정보를 큰 데이터베이스들에 유지 관리하는 DNS 서버들을 통해 도메인 명칭들을 IP 어드레스들로 변환하고("리졸빙(resolving)") 이의 최고 순위 도메인을 운영하는 임무를 맡는다. DNS는 IP 어드레스들 및 도메인 명칭들을 저장하고 있어 .com, .net, .edu, .tv와 같은 TLD들 내 어드레스들에의 서비스를 용이하게 한다. 리졸브는 도메인 명칭들이 대응하는 IP 숫자들에 맞추게 하는 프로세스이다. 리졸브는 어느 IP 숫자들이 한 특정한 도메인 명칭에 대응하는지를 판정하기 위해 DNS 내 데이터를 사용하는 명칭 서버들라고 하는 컴퓨터들 및 소프트웨어의 조합에 의해 달성된다. 여기에서는 다음의 일반적인 정의들이 사용될 것이다.

리졸브 ( resolve ): 도메인 명칭을 IP 어드레스로 전환하는 것.

리졸버 ( resolver ): 도메인 명칭을 리졸브하기 위해서 쿼리를 발행하는 컴퓨터.

명칭 서버: 쿼리들을 수신하고 이들에 대해 직접 혹은 다른 명칭 서버들에 대한 리졸브를 통해 응답하는 컴퓨터.

서브네트( subnet ): IP 어드레스의 옥텟들을 공유하는 일 그룹의 IP 어드레스들.

리졸버의 세트: 예를 들면, 서브네트들, 지리적 연관, 관리 실체 및 그외 IP 어드레스 관련과 같은 판정된 연결에 기초하여 함께 판단되는 하나의 그룹의 리졸버.

인터넷 도메인들은 서로 다른 레지스트리들이 이들 각각을 맡고 있는 이들의 TLD 서픽스(suffix)(예를 들면 .com, .net, co.uk...) - 에 따라 다수 그룹으로 분할될 수 있다. .com 및 .net 도메인들을 담당하는 VeriSign(등록상표) 레지스트리와 같이, 단일의 레지스트리가 이들 그룹들 중 몇개를 담당할 수도 있다.

DNS는 클라이언트-서버 모델을 사용하는 분산 데이터베이스 시스템에 의해 유지 관리된다. 이 데이터베이스의 노드들이 명칭 서버들이다. 각각의 도메인 또는 서브-도메인은 이 도메인에 관한 정보를 발간하는 하나 이상의 권한 있는(authoritative) DNS 서버 및 이에 부속된 임의의 도메인들의 명칭 서버를 갖는다. 계층의 최상위는 루트 명칭 서버에 의해 서비스되며 이들 서버들은 TLD를 참조(리졸빙)할 때 쿼리한다.

DNS는 각각의 도메인에 대해 권한 있는 명칭 서버를 지정함으로써 도메인 명칭을 할당하고 이들 명칭들을 IP 어드레스들에 매핑하는 임무를 분산한다. 권한 있는 명칭 서버들은 이들의 특정한 도메인을 담당하도록 할당된다.

이론적으로 전체 어드레스 도메인 명칭은 몇개의 명칭 세그먼트들을 지닐 수 있다(예를 들면 "www.one.type.example.com"). 실제로 도메인 명칭들은 빈번히 단지 3개의 세그먼트들로 구성될 것이다. 질의 목적을 위해서 명칭 세그먼트는 전형적으로 우측에서 좌측으로 세그먼트별로 해석된다. 해석 과정의 각 단계에서 참조해야 할 다음 서버에의 포인터를 제공하기 위해 대응하는 DNS 서버가 쿼리된다.

DNS에 의해 발생되는 방대한 분량의 요청 때문에, 리졸브 프로세스는 성공적 응답후에 기결정된 기간 동안 캐시해 둔다(즉, DNS 쿼리 결과들을 한 곳에 기록해두고 차후에 참조한다). 리졸버가 DNS 응답을 얼마나 오래동안 캐시할 것인가는(즉, 얼마나 오래동안 DNS 응답이 유효한 것인가 고려하는 것) 유효시간(time to live; TTL)이라고 하는 값에 의해 결정된다. TTL은 일반적으로 응답을 취급하는 DNS 서버의 관리자에 의해 설정된다. 유효성 기간은 단 몇 초 내지 몇 일 또는 심지어 몇 주로 다양할 수 있다.

캐시 기능뿐만 아니라 DNS 구조에 기초하여, 전형적으로 명칭 서버들에 적용되는 두 범주로서, 권한 있는 명칭 서버와 재귀적(recursive)(캐싱) 명칭 서버가 있다. 권한 있는 명칭 서버는 원래의 확정적 응답들("권한 있는" 응답들)을 DNS 쿼리들에 제공하는 명칭 서버이다. 모든 도메인 명칭에는 도메인 명칭을 리졸브하는 한 세트의 권한 있는 명칭 서버들이 할당되어야 한다.

전술한 바와 같이, DNS는 또한, 관계된 도메인 명칭 레코드의 DNS 쿼리 결과들을 기간이 결정된 TTL 동안 저장하는 재귀적 캐시 서버들을 사용한다. 전형적으로 이러한 캐시 DNS 서버들은 주어진 명칭에 대해 권한 있는 명칭 서버들에 이르기까지 DNS를 모두 검색하는 것부터 시작하여 주어진 명칭을 리졸브하는데 필요한 재귀적 알고리즘을 구현한다. 인터넷 서비스 제공자들(ISPs)은 전형적으로 이들의 고객들을 위해 재귀적 및 캐싱 명칭 서버들을 제공한다. 또한 많은 홈 네트워킹 라우터들은 국소적인 네트워크에서 효율을 개선하기 위해 DNS 캐시들 및 리커서(recursor)들을 구현한다.

DNS 명칭들을 IP 어드레스들로 리졸브하기 위해 근본적으로 캐시가 없는 애플리케이션으로서 동작하는 DNS "스터브(stub)" 리졸버들 또한 공지되어 있다. DNS 스터브 리졸버는 워크스테이션(또는 서버)용으로 구성된 DNS 서버에 DNS 쿼리들을 보내고 요청하는 소프트웨어에 대한 DNS 서버의 응답을 돌려준다. TTL이 만기가 되기 전에 캐싱 서버에 의해 유지되고 있는 레코드에 대해 스터브 리졸버가 캐시 명칭서버에 쿼리를 한다면, 캐싱 서버는 권한 있는 명칭 서버로부터 다시 검색해오지

현재 웹 트래픽 정보를 제공하기 위해 사용되는 몇가지 접근 방법들이 있다. 공지된 방법들은 사용자들 중 선택된 표본 사용자들의 웹 트래픽 사용을 모니터하는 클라이언트 에전트가 이들 표본 사용자들에 제공되는 패널-중심적 접근 방법들을 포함한다. 또한, 웹 사이트에 대해 웹 서버로부터 직접 웹 트래픽 통계들이 수집되는 사이트-중심적 접근 방법들이 있다.

그 밖의 방법들은 ISP에 집중하며 클라이언트에 웹 데이터를 제공하고 있는 ISP의 로그들로부터 웹 사용 트래픽을 수집한다. 그러나, 공지된 방법들 각각은 데이터가 수집되는 시점, 수집된 데이터량 및/또는 수집된 데이터의 자료성에 관계된 결점들을 안고 있다. 예를 들면 패널-중심적 애플리케이션들은 모니터링되고 있는 선택된 사용자들로 제한되기 때문에 인터넷 상에서 활동의 총체적 관점들을 얻는 능력에 한계가 있다. 또한 수 십억 개별적인 인터넷 사용자들의 활동을 분류하려는 어떠한 시도가 가능하다 하더라도 급속히 관리 불가한 레벨에 이르게 되는 막대한 데이터량을 요구할 것이다.

마찬가지로 개개의 웹 서버들에 대한 트래픽 스코어들은 운영자가 높은 트래픽량을 보고하는데 관심을 가질 수 있을 때 서버의 보고를 검증할 잠재적 필요성뿐만 아니라 상기 특정 서버에 의해 수집된 데이터의 분리된 특성에 기초하여 제한된 값을 가질 수 있다. 또한, 이러한 트래픽 모니터들은 트래픽 량에 간섭하거나 인위적으로 부풀릴 수 있는 다양한 유형들로 위장되기 쉽다. ISP들은 이들의 특정한 클라이언트 기반, 지리적 관심, 및 특정 ISP가 인지해도 되는 트래픽을 본질적으로 또는 암묵적으로 제한하는 그 밖의 요인들에 의해 인터넷의 전체적 활동을 특정하는 능력에는 한계가 있다.

도메인들에 대해 정확하고 의미있는 트래픽 순위를 결정하는데 있어 문제들이 존재한다. 일반적으로 인터넷 트래픽은 2개의 그룹들로서 사용자 본위의 트래픽 및 기계 본위의 트래픽으로 분류될 수 있다. 사용자 본위의 트래픽은 웹 사이트들을 열람하는 사용자들에 의해 생성되는 활동으로서 간주될 수 있다. 기계 본위의 트래픽은 자동적 프로세스들 및 서비스들(예를 들면 안티바이러스 업데이트 운영 시스템 업데이트, 웹 서비스등)에 의해 발생되는 활동으로서 간주될 수 있다.

온라인 광고를 포함하는 상업적 목적을 위해서 웹 사이트에 구동된 사용자 발생 트래픽을 확인하는 것이 특히 중요하다. 그러므로 사용자 본위의 트래픽을 측정하는 방법들이 바람직하다. 그러나 이것은 예를 들면 요청자의 특성에 관한 정보가 입력 쿼리 자체들로부터 얻어질 수 없기 때문에 상당한 문제가 된다. 트래픽 유형들 간을 구별하는데 있어 또 다른 문제는 중간 DNS 리졸버들에 의해 개시된 쿼리들을 참조하는 인터넷 DNS 시스템의 구조에 의해 야기된다. 이것은 요청을 개시한 최종-사용자의 특성을 모호하게 할 수 있다.

본 발명은 TLD DNS 서버들에서 얻어지는 DNS 트래픽 데이터를 사용하는 다양한 메커니즘들을 통해 위에 문제들을 해결한다. 발명의 실시태양에서 인터넷 전역에 걸쳐 있는 도메인들은 공지된 시스템들이 구상하거나 달성하지 못한 방법들로 랭크될 수 있다. 실시예들에서 몇몇 특성들 및/또는 측정들은 여러 도메인들에 대한 TLD DNS 서버에서 파악되고 트래픽 스코어들을 계산하기 위해 사용되는 DNS 트래픽으로부터 얻어질 수 있다. 계산된 스코어들은 도메인의 순위를 결정하기 위해 사용될 수 있다.

발명자들은 DNS 데이터를 의미있고 유용한 형태로 변환하는데 있어 문제는 DNS 데이터의 크기임을 알았다. 레지스트리들은 세계의 서로 다른 부분들에 위치된 몇몇 리졸브 사이트들을 운영할 수 있다. 하나의 레지스트리를 위한 사이트들은 하루에 340억 쿼리들에 대해 응답할 수 있다. 이 막대한 수의 쿼리들은 데이터 그대로를 해석하려 하지만 막대한 과제가 된다. 본원은 전체 데이터량을 더욱 관리가능한 크기로 줄일 수 있는 데이터 집적을 위한 시스템 및 방법을 제공한다. 이들 방법에 따라서, 트래픽 데이터 그대로를 사용하는 종래의 방법에 의해 달성되었던 것 이상으로 인터넷 상에 의미있는 활동의 더욱 정확한 기재를 개발할 수 있음을 인지하게 되었다.

개시된 방법들은 예를 들면 하루에 도메인 당 몇몇 통계들을 나열할 수 있는 도메인이 요약된 트래픽 정보, 및 DNS 쿼리들에 관한 더욱 상세한 정보를 나열할 수 있는 도메인의 상세한 트래픽 정보를 포함하는 서로 다른 집적 포맷들을 포함할 수 있다. DNS 쿼리 정보의 특히 유용한 예는 쿼리들을 발생하는 한 세트의 리졸버들의 식별 신호임을 알았다.

실시예는 DNS 쿼리들에서 요청된 어드레스의 유형들 간을 구별하는 것을 포함할 수 있다. 예를 들면, 실시예들은 개별적으로 정확한(exact) 요청, "www" 요청, 및 기타(other) 요청을 인식할 수 있다. 여기에서 사용되는 바와 같이, 정확한 요청은 특정한 개수의 라벨들과 같은 미리 결정된 기준에 부합하는 요청이다. 정확한 요청들은 이를테면 어떠한 프리픽스도 없이 요청된 정확한 두번째 레벨 도메인 명칭과 같이 2개의 라벨들을 포함하는 것으로서 실시예에서 확인될 수 있다. 예를 들면 도메인 "example.com"에 대한 정확한 요청은 "http://example.com/"일 수 있다.

"www" 요청은 문자 스트링 "www"이 프리픽스에 포함된 요청이다. 예를 들면 "http://www.example.com/", "http://wwwl.example.com/", 및 "http://AAA-www.example.com/"로 나타난 요청은 "www" 요청들로서 인식된다. 여기에서 사용되는 바와 같이, "기타" 요청은 "정확한" 또는 "www" 기준 어느 것도 충족하지 않는 요청이다. 이것은 요청의 부분으로서 다른 프리픽스들을 포함할 수 있다. 예를 들면, "http://jobs.example.com/", "http://mail.example.com/", 및 "http://AAA.BBB.example.com/"은 어떤 대응하는 정확한 일치도 확인되지 않았다면 "기타" 요청들로서 인식될 것이다.

실시예에서, 도메인에 대한 DNS 쿼리들에 관한 다음 예시적 속성들이 얻어져 순위를 계산하는데 사용될 수 있다.

WWW 요청 히트. 첫 번째 라벨에 "www"에 DNS 레코드들 상에 히트들의 카운트.

정확한 요청 히트들. 단지 2개의 라벨들, 예를 들면 "example.com"에 DNS 레코드들 상에 히트들의 카운트.

또 다른 요청 히트들. 위에 어느 카테고리에도 속하지 않는 DNS 레코드들 상에 히트들의 카운트.

이하 더 설명되는 바와 같이 실시예는 트래픽 및/또는 순위 스코어들을 결정함에 있어 도메인에 대한 각종의 요청 히트들에 적합한 가중치들을 적용하는 것을 포함할 수 있다.

실시예는 DNS 쿼리의 발원 IP 어드레스, 서브네트, 및/또는 리졸버의 세트에 관계된 다음의 속성들을 고려하고 순위를 계산하기 위해 이들을 사용하는 것을 포함할 수 있다.

WWW 서버 카운트. 첫 번째 라벨에 "www"에 DNS 레코드가 일치하는 고유한 하향 IP 어드레스들 또는 한 세트의 리졸버들의 카운트.

정확한 서버 카운트. 단지 두 라벨들에 DNS 레코드가 일치하는 고유한 하향 IP 어드레스들 또는 한 세트의 리졸버들의 카운트.

또 다른 서버 카운트. 위에 어느 카테고리에도 속하지 않는 DNS 레코드들에 일치하는 고유한 하향 IP 어드레스들 또는 한 세트의 리졸버들의 카운트.

이하 더 설명되는 바와 같이 실시예는 트래픽 및/또는 순위 스코어를 결정함에 있어 도메인에 대한 각종의 서버 카운트에 적합한 가중치를 적용하는 것을 포함할 수 있다.

실시예는 도메인에 대한 DNS 기록의 TTL에 기초하여 트래픽 및/또는 순위 스코어를 계산하는 것을 포함할 수 있다.

실시예는 도메인 트래픽을 판정하기 위한 자동화된 방법을 포함할 수 있다. 방법은 마침표에 의해 분리된 n 라벨을 갖는 도메인 명칭을 리졸브하라는 요청을 권한 있는 명칭 서버에서 수신하는 단계를 포함할 수 있다. 맨 왼쪽 라벨은 첫 번째 라벨이며 TLD는 n 번째 라벨이다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함한다면 도메인 명칭에 대한 www 카운터가 증가(increment)될 수 있다. 수신된 도메인 명칭이 단지 두 라벨만을 갖는다면 도메인 명칭에 대한 정확한 카운터가 증가될 수 있다.

수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않으며 단지 두 라벨들만 갖는 것도 아니라면 도메인 명칭에 대한 또 다른 카운터가 증가될 수 있다. 다수의 카운터에 기초하여 도메인 트래픽 스코어가 계산될 수 있다. 도메인 트래픽 스코어를 계산하는 단계는 카운터들 중 적어도 하나에 가중치를 적용하는 단계를 포함할 수 있다.

실시예는 위에 나타낸 바와 같이 도메인 명칭을 리졸브하라는 요청을 권한 있는 명칭 서버에서 수신하는 단계를 포함할 수 있다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함한다면, 도메인 명칭에 대한 www 히트 카운터 및 www 요청 서버 카운터 중 적어도 하나가 증가될 수 있다.

수신된 도메인 명칭이 단지 두 라벨만을 갖는다면 도메인 명칭에 대한 정확한 히트 카운터 및 정확한 요청 서버 카운터 중 적어도 하나가 증가될 수 있다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않으며 단지 두 라벨들만 갖는 것도 아니면 도메인 명칭에 대한 또 다른 히트 카운터 및 또 다른 요청 서버 카운터 중 적어도 하나가 증가될 수 있다. 다수의 상기 카운터들에 기초하여 도메인 트래픽 스코어가 계산될 수 있다. 도메인 트래픽 스코어를 계산하는 단계는 카운터들 중 적어도 하나에 가중치를 적용하는 단계를 포함할 수 있다.

실시예는 권한 있는 명칭 서버가 TLD 명칭 서버임을 포함할 수 있다.

실시예는 미리 결정된 기간 동안 특정 카운터들 상에 등록하는 증가들의 수를 제한하는 단계를 포함할 수 있다. 예를 들면 요청 서버 카운터는 24 시간당 1회 증가(카운트)로 제한될 수 있다. 실시예는 미리 결정된 기간 후에 카운터를 리세트하는 단계를 포함할 수 있다.

실시예는 도메인에 대한 상대적 트래픽 스코어에 기초하여 순위 스코어를 계산하는 것을 포함할 수 있다. 이것은 도메인 트래픽 스코어를 다른 도메인 트래픽 스코어들과 비교하는 단계를 포함할 수 있다. 계산된 트래픽 및/또는 순위 스코어들은 요금 서비스의 부분으로서 자동으로 분배될 수도 있고 혹은 광고료 등과 같은 다른 항목들을 결정하는데 사용될 수도 있다.

본 발명의 다른 이점들은 바람직한 실시예의 다음 상세한 설명을 통해 이해했을 때 당업자들에게 명백하게 될 것이다.

도 1은 본 발명의 하나의 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 2는 본 발명의 하나의 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 3은 본 발명의 하나의 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 4는 본 발명의 하나의 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 5는 본 발명의 하나의 실시예에 따른 예시적인 방법의 측면들을 도시한 것이다.
도 6은 본 발명의 하나의 실시예에 따른 예시적인 시스템 및 관계된 네트워크를 도시한 것이다.
도 7은 도메인 트래픽 크기와 "기타" 타겟으로 향하는 트래픽의 퍼센티지 간에 관계를 반영하는 차트를 도시한 것이다.
도 8은 도메인 트래픽 크기와 "WWW" 및 "정확한" 타겟으로 향하는 트래픽의 퍼센티지 간에 관계를 반영하는 차트를 도시한 것이다.
도 9는 발명의 또 다른 측면에 따라 그룹화된 도메인들의 수를 반영한 차트를 도시한 것이다.

다음 상세한 설명은 설명 및 이해를 쉽게 하기 위해 예시적 실시예에 관련하여 제공된다. 출원인의 발명은 개시된 실시예로 제한되지 않으며, 여기에 제공된 설명의 전체 범위 내에 속하는 다른 변형을 포함한다.

전술한 바와 같이, 본 발명의 실시예는 도 1에 도시된 인터넷 환경과 같은 네트워크 상에서 동작들을 포함할 수 있다. 클라이언트 계산장치(110)는 재귀적 명칭 서버(130)에 DNS 요청(103)을 개시할 수 있다. 도 1에 제시된 바와 같이, DNS 요청들(103)은 모바일 기기(120), 무선 계산장치(122), 그외 통신 링크(124), 및/또는 중간 네트워크 서버들(126)와 같은 다양한 소스들로부터 비롯되거나 이들로부터 재귀적 명칭 서버(130)에 송신될 수 있다.

도메인 명칭을 리졸브하라는 DNS 요청은 전형적으로 마침표에 의해 분리된 n 개의 라벨을 갖는다. 이들 라벨은 일반적으로 희망하는 인터넷 자원 예를 들면 웹 페이지에 대한 숫자로 된 IP 어드레스보다는 기억하기 쉬운 어떤 형태로 되어 있다. 설명을 쉽게 하기 위해서 맨 왼쪽 라벨은 첫 번째 라벨로 간주하고 TLD는 n 번째 라벨이다.

따라서 "www.example.com"에 대한 요청에서 n = 3이며, 첫 번째 라벨은 "www"가 될 것이며 TLD는 ".com"이 될 것이다. 위에 기술된 바와 같이 재귀적 명칭 서버(103)는 DNS 요청을 재귀적 명칭 분해의 부분으로서 여러 권한 있는 서버들(140, 150, 160)에 송신할 수 있다. 대안적으로 요청된 DNS 정보는 DNS 레코드의 TTL이 적용되는 재귀적 명칭 서버(130)의 캐시 내에 보관할 수 있는데, 이 경우 쿼리는 권한 있는 명칭 서버들(140, 150, 160)을 참조함이 없이 응답될 수 있다.

도 2는 재귀적 명칭 서버(220) 및 이것이 권한 있는 명칭 서버들(230, 24, 250)과 상호작용하는 것을 더 상세히 도시한 것이다. 도 2에서 권한 있는 서버들(230)은 루트 레벨 권한 있는 서버들이다. 이들 서버들 각각은 인터넷 상에 특정 TLD들에 대한 정보를 내포한다. 루트 레벨 서버들은 이들의 TLD 내에 도메인들에 대한 요청들을 이 TLD 레지스트리에 의해 관리되는 다른 권한 있는 서버들에 보낼 수 있다.

예를 들면 클라이언트(210)로부터 DNS 요청(202)은 "www.example.com"에 대한 요청을 포함할 수 있다. 재귀적 명칭 서버(220)는 먼저 대응하는 DNS 레코드에 대해 내부 캐시를 체크할 수 있다. 발견되는 것이 없다면, DNS 요청은 203에서 루트 레벨 권한 있는 명칭 서버들(230)에 보내질 수 있다. 서버들(230) 가운데 ".com"을 담당하는 권한 있는 루트 레벨 서버는 요청자를 권한 있는 명칭 서버들(240)에 보내는 "example.com"에 대한 DNS 정보를 보낼줄 수 있는데, 이 경우 이들 서버들은 ".com"의 레지스트리에 대한 일단의 서버들을 나타낸다.

여기에 기술된 바와 같이, DNS 요청들, 예를 들면, 203, 204, 205는 여러 권한 있는 서버들, 예를 들면 230, 240, 250에서 카운트될 수 있다. 실시예에서, 카운트하는 것은 예를 들면, 230과 같은 TLD 명칭 서버에서 행해질 수 있다. 다른 권한 있는 명칭 서버들(240, 250)은 각각의 서버에 의해 취급되는 레코드들에 대한 DNS 히트들을 카운트할 수도 있다. 실시예들은 조합된 순위에 도달하기 위해서 여러 서버들, 및/또는 TLD들, 예를 들면 ".com.", ".net", ".edu", ".uk"로부터 스코어들을 조합하는 것을 포함할 수 있다.

실시예에서, 주어진 카운터로 요청을 카운트할지 하지 않을지에 대해 판정이 행해질 수 있다. 예를 들면 "서버 카운터"와 같은 어떤 카운터들은 미리 결정된 기간당 단일 카운트로 제한될 수 있다. 도 3에 도시된 바와 같이 요청이 S3100에서 수신될 수 있다. 관계된 히트 카운터가 S3200에서 증가될 수 있다. S3300에서 서버 카운터를 증가 시킬지에 대해 판정이 행해질 수 있다. 이 실시예에서 서버 카운터의 현재 카운트는 미리 결정된 값 "X"와 비교될 수 있다. 서버 카운트가 X보가 크거나 같다면, 서버 카운터를 다시 증가 시킬지에 대한 판정이 행해지고 방법은 S3500로 갈 수 있다. 서버 카운트가 X 미만이라면, 방법은 서버 카운터가 증가되는 S3400로 진행한다. 서버 카운트는 미리 결정된 기간 후에 자동으로 리세트될 수 있다.

서버 카운터 맥락에서 기술되었을지라도 특정한 IP 어드레스, 한 세트의 리졸버 등에 연관된 카운터들과 같이 다른 카운터들이 유사한 방식으로 제한될 수 있다. 이하 더욱 기술되는 바와 같이 어떤 카운터들의 카운트를 제한하는 것은 의미있는 인터넷 활동들의 더 정확한 묘사를 개발하기 위해 사용될 수 있다. 이들 제한된 카운터들은 전체 웹 트래픽의 관리가능하고 정확한 표현을 사용자들에게 제공하기 위해 단독으로 혹은 히트 카운터들과 조합하여 고려될 수 있다. 예를 들면 제한된 카운터를 사용하는 것은 특정 서버, 한 세트의 리졸버들, IP 어드레스 등으로부터 비롯될 수 있는 인위적인 혹은 신뢰할 수 없는 트래픽 표시자들이 미치는 원하지 않는 영향을 감소시킬 수 있다.

도 4를 참조하면 예시적인 방법들은 S4000에서 수신된 요청에 관하여 카운터를 증가시켜야 할지를 판정하는 단계를 포함할 수 있다. 위에서 상세히 한 바와 같이, 일부 실시예에서 도메인에 대한 수신된 DNS 요청들에 대해 히트 카운터가 증가될 수 있다. 어떤 경우들에 있어서 제한된 카운터는 증가되지 않을 것으로 판정될 수도 있다. 관련 카운터가 증가될 것 경우엔, 방법은 S4100으로 갈 수 있다.

S4100에서 요청은 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하는지 여부를 판정하기 위해 평가될 수 있다. 스트링은 "www.example.com"의 경우와 같이 혹은 "www1.example.com"와 같이 다른 문자들로 네스트된 경우와 같이 요청된 어드레스의 독립된 부분일 수도 있다. 첫 번째 라벨이 스트링 "www"를 포함하는 것으로 판정된다면, 방법은 S4200으로 진행하여, 도메인 명칭에 대한 www 카운터와 같은 카운터 "A"가 증가될 수 있다. 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지 않는다면, 방법은 S4300으로 진행할 수 있다.

S4300에서 라벨들이 미리 결정된 조건 "R(r)"을 만족하는지 여부를 판정하기 위해 요청이 평가될 수 있다. R(r)은 미리 결정된 수의 라벨, 명시된 스트링, 혹은 DNS 요청의 그외 다른 특징들을 포함하는 많은 형태들을 취할 수 있다. 다수의 라벨들을 지정하는 경우에 기술된 실시예는 R(2) = 두 라벨들인 경우를 포함한다. 수신된 도메인 명칭이 라벨들의 미리 결정된 수 R(2)만을 갖는다면,

예를 들면 "example.com"에서 2개의 라벨들만을 갖는다면, 방법은 S4400으로 진행하여 도메인 명칭에 대해 2-라벨 "정확한" 카운터 B(2)와 같은 카운터 B(r)가 증가된다. 요청이 라벨들의 설계된 개수 R만을 갖지 않는다면, 예를 들면 라벨들의 기결정된 수 R가 2일 때 2 이상의 라벨들을 갖는다면, 방법은 S4310으로 진행할 수 있다.

실시예는 복수의 B 카운터들, 예를 들면 복수의 정확한 카운터들을 포함할 수 있다. 이들은, 예를 들면, R(r)에 대한 여러 개수들에 대해 개별적 카운터들 혹은 도메인 스트링들의 정확한 부분들에 대해 "정확한" 카운터들의 다른 버전들을 포함할 수 있다. 예로서, 추가의 카운터 B(3)는 R = 3인 "mail.example.com"에 대한 요청에 응하여 증가될 수 있다. 또 다른 예로서, 한 특정한 스트링 예를 들면 "mail"을 가진 요청들은 요청이 스트링, 예를 들면 "mail5.example.com"을 내포할 때, 카운터 B("mail")에 의해 카운트될 수 있다. 이것은 S4310에서 추가의 정확한 카운터들 B(r)이 구현되고 있는지 여부를 판정함으로써 구현될 수 있다.

다른 정확한 카운터들이 있다면 방법은 카운터 B(r)에 대한 새로운 값으로 R(r)이 리세트되는 S4320으로 진행할 수 있다. R(r)이 리세트된 후에, 방법은 다시 S4300으로 계속되어 요청들이 새로운 기준 R(r)을 만족하는지를 판정할 수 있다. S4300, S4310 및 S4320은 R(r)이 만족될 때까지 혹은 남아있는 정확한 카운터들이 없을 때까지 반복될 수 있다. 남아있는 정확한 카운터들이 없다면, 방법은 S4500로 진행할 수 있다.

S4500에서 도메인 명칭에 대한 기타 카운터와 같은 카운터 "C"가 증가될 수 있다. 기타 요청들, 즉 전술한 카테고리들 중 어느 것도 충족시키지 않는 요청들을 카운트할 필요가 없을지라도, 기타 카운터는 검출된 트래픽의 중요성을 평가하는데 잇점들을 제공할 수 있다. 예를 들면 기타 카운터는 사람 상호작용에 의해 명백하게 구동되는 트래픽의 퍼센티지를 판정하기 위해 www 카운터 및 정확한 카운터(들)와 비교하여 사용될 수 있다.

S4210, S4410, 및/또는 S4510에서 가중치가 결정되고 및/또는 각각 카운터들 A, B(r) 및/또는 C에 할당될 수 있다. 가중치들은 도메인에 대한 카운터들 모두에 혹은 그 미만에 적용될 수 있다. 예를 들면, 가중치는 도메인에 대한 하나, 둘, 혹은 모든 카운터들에 적용될 수 있다. 가중치를 할당하는 것은 카운터의 특성에 관계된 몇가지 팩터들 및 도메인에 관하여 수집된 다른 정보에 기초할 수 있다.

가중치들은 또한 동적으로 적용될 수도 있다. 예를 들면, 시간에 따라, 도메인에 대한 서로 다른 카운터들의 카운트들은 변할 수 있고 혹은 도메인에 관하여 정보가 전개될 수도 있다. 이것은 도메인에 대한 카운터들에 적용되는 가중치들 중 하나 이상의 변경을 촉발시킬 수 있다. 방법은 S4900에서 계속될 수 있다.

S4900에서 트래픽 스코어와 같은 스코어가 도메인에 대해 계산될 수 있다. 트래픽 스코어는 복수의 카운터들에 기초할 수 있다. 모든 관계된 카운터들로부터의 카운트들을 사용할 필요는 없음에 유의한다. 스코어들은 임의의 관계된 가중치들이 고려된 상태에서, 하나, 둘 또는 그 이상의 카운트들에 기초하여 계산될 수 있다. 따라서, 도메인 트래픽 스코어는 복수의 카운터들에 기초하여 계산될 수 있고, 카운터들 중 적어도 하나에 가중치를 적용하는 것을 포함할 수 있다.

앞에서 언급한 바와 같이 재귀적 명칭 서버가 DNS 쿼리에 대한 응답을 얻었을 때, 이를 차후에 사용하기 위해 캐시해 둘 수 있다. 각각의 응답이 캐시에 저장되는 시간은 TTL에 기초한다. 발명자들은 도메인을 타겟으로 한 총 쿼리 수에 의해 도메인의 트래픽을 측정하는 것은 캐시 기능 및 DNS 레코드에 대한 TTL에 근거하여 부정확성들을 가질 수 있음을 관찰하였다. 캐시 기능을 보상하는 것은 각각의 도메인/리졸버가 이의 TTL을 다르게 관리할 수도 있다는 사실에 근거하여 대규모 구현들에 있어선 특히 어려울 수 있다.

예를 들면 리졸버는 이의 캐시를 매 6 시간마다 리프레시할 수 있고, 또 다른 리졸버는 이의 캐시를 매 12 시간마다 리프레시할 수도 있다. 두 리졸버들이 한 주어진 도메인에 대해 정확한 횟수만큼 요청을 받을지라도, 개략적으로 말하여, 첫 번째 리졸버는 두번째 리졸버에 비해서, 두 리졸버들이 동일한 량의 사용자-발생 트래픽을 도메인에 나타내고 있더라도, 이 도메인에 대한 DNS 체인에서 쿼리 트래픽량에 두 배를 발생시킬 것으로 예상될 것이다. 발명자들은 이 문제를 해결하기 위해 몇 가지 특징들을 개발하였다.

하나의 예로서 가중 스코어는 DNS 파일에 대한 TTL에 기초하여 S4900에서 적용될 수 있다. 이것은 실제로 서버에 보내지는 요청들만을 보는 권한 있는 명칭 서버들에 링크된 히트 카운터들의 한계를 어느 정도 보상할 수 있다. 서버에 보내지는 요청들의 수에 기초하여, TTL에 기초한 가중치는 도메인에 보내지고 있는 총 트래픽의 추청치를 계산하기 위해 사용될 수 있다. 일반적으로 상대적으로 긴 TTL을 가진 사이트들에 있어 트래픽은 짧은 TTL들을 가진 것들보다 큰 가중치를 받을 수 있다. 가중치들은 스코어/순위로된 도메인들 간에 TTL들의 비에 기초하여 설정될 수 있다.

또 다른 예로서 개시된 방법들은 각각의 개개의 리졸버의 TTL 및 캐싱 정책에 잡음 및 의존성을 덜 야기하는 것으로 발견된 서로 구별되는 질의하는 IP 어드레스들, 한 세트의 리졸버들, 등의 수를 관찰하는 것에 관한 것이다. 이 접근 방법은 방대한 량의 전체 트래픽을 볼 수 있는 TDL 및 그외 권한 있는 명칭 서버들의 레벨에서 트래픽을 관찰하는 분야에서 특히 유용할 수 있는 것으로 발견되었다. 고유하게 질의하는 IP 어드레스들, 다수 세트의 리졸버들, 등의 메트릭(metric)은 총 히트 카운터들에 의해 수신되는 큰 오프셋들을 방지할 수도 있다. 예를 들면, 히트 카운터에 의해 반영되는 총 트래픽량에만 의존하기 보다는, 각각의 서로 구별되는 질의하는 IP 어드레스들, 한 세트의 리졸버들, 등은 기결정된 기간, 예를 들면 24-시간마다 한번만 카운트될 수도 있다.

이에 관하여 2가지 유형들의 메트릭들을 고찰하는 것이 유용하다:

히트들(H): 주어진 도메인에 대해 발생된 총 쿼리 수.

리졸버의 세트(S): 구별된 리졸버 IP 어드레스들, 서브 세트들, 리졸버들의 세트들, 및 주어진 도메인에 대해 쿼리들을 발생시키는 기타 같은 종류의 것의 수.

상기한 바와 같이 주어진 쿼리는 3가지 유형들의 도메인 타겟들인, www, 정확한, 기타 중 한 유형을 요청할 수 있다. 발명자들은 각각의 요청들의 카운트들에 기초하여 트래픽의 특성을 의미있게 해석하는데 도움을 주는 몇가지 인자들을 관찰하였다. 이것은 웹 서비스들, 등과 같은 비-사용자 트래픽과는 반대로 한 특정한 유형의 각각의 쿼리가 사용자 트래픽을 반영하는 정도를 이해하는데 도움을 줄 수 있다.

www 쿼리들에 관하여 이러한 타겟들을 참조하는 대다수의 트래픽은 사용자-본위인 것으로 가정할 수 있다. 그러나 www 쿼리들이 전형적으로 도메인에서 사용자-본위 트래픽을 반영하나, 이들은 항시 도메인에 대한 모든 사용자-본위 트래픽을 포함하지 않는다. 일부 도메인들에 있어서, 사용자-본위 트래픽의 일부는 "정확한" 및 "기타" 메트릭들 내에 있음이 발견되었다. 예를 들면 발명자들은 일부 인기있는 웹 사이트들에 있어서, 요청들 중 10% 미만은 www 카테고리에 속함을 발견하였다.

그러므로 www 메트릭에만 기초하여 스코어를 계산하는 것은 웹 사이트가 보고 있는 실제 트래픽에 기초하였을 것보다 어떤 웹 사이트들이 훨씬 낮게 랭크되는 것을 초래할 수 있다. 이것은 "또 다른" 쿼리들이 사용자-본위 트래픽의 대부분을 포함할 수 있는 큰 도메인들의 인기도를 평가하는데 있어 특히 관계가 있는 있는 것으로 발견되었다. 예를 들면, 도메인 "example.com"은 대부분의 트래픽이 인기있는 서브-도메인들, 예를 들면, mail.example.com; games.example.com; news.example.com; 등에 보내지는 것을 볼 수 있다.

발명자들은 도메인의 크기(즉 이의 트래픽량)과 이의 전체 트래픽 중 "또 다른" 트래픽의 퍼센티지 간에 큰 상관이 있음을 발견하였다. 도 7은 도메인 트래픽 크기(로그 공간에서)와 "또 다른" 타겟들(서브-도메인들)로 진행하는 트래픽의 퍼센티지 간에 관계를 도시한 것이다. 각 바(bar)의 값은 이 바 내에 위치된 모든 도메인의 퍼센티지의 평균인 것에 유의한다.

이것은 두 팩터들 간에 명백한 관계를 보여주는 것으로, 더 큰 도메인들은 "또 다른" 트래픽에서 이들의 총 트래픽의 더 큰 퍼센티지를 갖는 경향이 있음을 의미한다. 따라서, "또 다른" 트래픽의 중요도는 도메인에 대한 트래픽의 전체 레벨에 따라 달라질 수 있다. 이러한 관찰은 여기에 기술된 다양한 방법들을 수립할 때 고려되었다. 예를 들면, 또 다른 트래픽에는 일반적으로 정확한 트래픽보다는 낮은 가중치가 주어질지라도, 실시예에서, 또 다른 트래픽에 대한 가중치는 상대적 트래픽량에 따라 증가될 수도 있다.

사용자들에 의한 웹 사이트들에 대다수 의뢰에서 "www" 프리픽스는 생략된다(예를 들면 "example.com"). 그러나, 이러한 요청들에 의해 반영되는 사용자-본위 대 비-사용자 본위의 트래픽의 비율, 따라서 "정확한" 요청들의 중요도는 확실하지 않았다.

발명자들은 "www" 및 "정확한" 트래픽 메트릭 둘 다를 고려하는 것은 특히 유리한 결과들이 얻어지게 한다는 것을 관찰하였다. "정확한" 메트릭 단독으로는 명백한 경향 또는 일관성을 이행하지 못하나, "www" 메트릭과 결합되었을 때에는 명백한 패턴이 관찰된다. 따라서, 두 메트릭들은 도 8에 도시된 바와 같이, 예기치 않은 방법으로 서로를 보완하는 것으로 판정되었다.

발명자들은 주어진 기간 내에 주어진 도메인의 입력되는 트래픽을 이 기간 내에 전체 트래픽과 비교함으로써 이 주어진 도메인의 수행을 측정하기 위한 능률적이고 정확한 접근 방법을 개발하기 위해 전술한 관찰에 의존하였다. 실시예에서, 모든 3개의 DNS 타겟 유형들, 예를 들면 www (W), 정확한 (E) 및 기타 (O)가 포함될 수 있으며, 각각은 다른 가중치가 할당될 수 있다. 추가의 특징으로서 "리졸버들의 세트" 메트릭들은 단독으로, 혹은 "히트" 메트릭들과 조합하여 사용될 수 있다. 예를 들면, 다음은 개시된 방법들의 실시예를 나타낸다.

주어진 기간동안 각각의 도메인의 일자별 W/E/O 평균 비들을 계산한다. 즉, 각각의 도메인에 대해서, 이의 구별되는 한 세트의 리졸버들의 메트릭과 이 날에 서로 구별되는 한 세트의 리졸버들의 전체 수 간에 일자별 비의 평균을 계산한다. 이것은 타겟 유형들 각각에 대해 개별적으로 행해질 수 있다; W/E/O:

여기서 D는 도메인; P는 기간(|P|는 일 수별 기간의 크기이다); 따라서 S_W/E/O(모두, Dayi)는 W/E/0를 쿼리하는 서로 구별되는 리졸버들의 세트들의 전체 수이다.

주어진 기간 내에 도메인에 대한 전체 스코어를 계산한다.

따라서, W_W _/E/O는 타겟 유형들 W/E/O 각각의 가중치이다. 바람직한 실시예에서, 다음 근사적인 가중치들이 위에 식에서 사용될 수 있다.

W_W = 1

W_E = 0.5

W_o = 0.2

다른 실시예에서 가중치들은 보다 일반적으로 기술될 수 있다. 예를 들면, W_W ≥ W_E ≥ W_o이다. 앞에서 제시된 바와 같이, W_o는 트래픽량에 따라 조절될 수 있다. 예를 들면, W_o는 W_o' = (W_OK)로서 정정될 수 있는데, K는 K ≥ 1이 비교적 큰 트래픽량이고 K ≤은 비교적 작은 량의 트래픽을 나타내게 하는 도메인 트래픽량의 상대적 팩터이다.

발명자들은 유사한 스코어들을 그룹화하는 것이 여러 사용자들에게 정보의 유용성을 개선할 수 있음을 알았다. 예를 들면, 그룹들의 유용한 표현은 스코어들의 로그를 100개의 동일 폭의 빈들(bins)로 분할함으로써 생성될 수 있으며 여기에서 1은 가장 낮은 것이고 100은 가장 큰 것이다. 도 9는 각 그룹 내 도메인들의 수를 보인 것이다.

실시예에서 광고 가격은 도메인에 대한 그룹에 기초하여 결정될 수 있다. 예를 들면, 90 내지 100 사이의 트래픽 그룹 내 도메인은 50 내지 60 사이의 트래픽 그룹 내 도메인과는 반대로 그에 적용되는 광고료는 다를 수 있다. 이들 그룹들은 원 트래픽 스코어 데이터로 한정되는 것은 아니며 TLD 서버의 레벨로부터 얻어지는 넓은 관점뿐만 아니라, 여기에 기술된 방법들에 기초하여 더 의미있고 가치있는 메트릭을 나타내는 것에 유의한다. 예를 들면, 발명자들은 여기에서 논한 방법들은 낮은 레벨로 트래픽을 전개하고 있는 웹 사이트들 및 도메인들을 종래의 방법들보다 앞서 식별할 수 있음을 관찰하였다. 이러한 결과들은, 부분적으로, 인터넷 전체에 걸쳐 이로부터 트래픽을 종합하고 이의 중요도를 평가하는 TLD의 능력에 기초하여 얻어질 수 있다.

도 5를 참조하면, 실시예들은 S3990, S4900, 및/또는 S5900에서와 같이, 계산된 스코어를 취하는 단계, 및 이 스코어를 사용하여 도메인을 랭크하는 단계를 포함할 수 있다. 예를 들면 도메인에 대해 계산된 트래픽 스코어는 이 도메인을 웹 상에 다른 도메인들 간에 랭크하기 위해서 S5910에서 다른 계산된 스코어들에 비교될 수 있다. 이러한 랭크는 사용자들이 특정 도메인에 광고하는 것에 대한 적합한 가격 또는 값을 평가하기 위해 더 직관적인 방법으로 사용될 수 있다. 계산된 순위는 유료 서비스의 부분으로서 분배될 수도 있고, 혹은 시스템 관리, 등을 포함한 다른 목적들을 위해 사용될 수도 있다.

또한, 도메인 순위는 S5920에서 값을 계산하기 위해, 광고와 같은 상업용 서비스들의 맥락에서 사용될 수 있다. 예를 들면 특정 도메인에 광고하는 값은 자동화된 온라인 광고료들을 제공하는 순위-기반 식에 링크될 수도 있다. 이러한 시스템들은 현재의 방법들을 사용하여 가능하지 않은 방법들로 중요한 트래픽을 보는 것을 시작하고 있는 웹 사이트 개발자들을 평가하고 보상하기 위해 사용될 수 있다. 예를 들면 TLD 서버, 혹은 개시된 정보에 액세스할 수 있는 다른 벤더는 잠재적 광고주들로부터의 제의들을 특별한 랭크를 충족하는 도메인들에 자동으로 제공할 수 있다. 위에 나타낸 바와 같이, 발명자들은 권한 있는 서버, 특히 TLD 서버의 위치로부터 보았을 때, 잠재적 광고주들이 관심을 가질 수 있는, 이전에 인식되지 않은 저-레벨 트래픽 사이트들을 식별하는 것이 가능함을 발견하였다.

본 발명의 실시예는 컴퓨터로 하여금 기술된 방법들을 실행하게 하기 위한 명령들이 부호화된 컴퓨터-판독가능 저장 매체뿐만 아니라, 기술된 방법들을 구현하는 시스템들을 포함할 수 있다. 예를 들면 도 6에 도시된 바와 같이, 프로세서, 메모리 및 전자 통신 기기를 포함하는 전자 시스템(600)은 ISP 서버(650)를 통해 DNS 정보를 요청하게 구성될 수 있다. 시스템(600)은 사용자 컴퓨터 시스템, 620, 670과 같은 무선 통신 기기들, 630, 690과 같은 서브 네트워크들, 서버 혹은 필수 기능 능력들을 갖춘 그외 어떤 다른 네트워크 가능 기기를을 나타낼 수 있다. 서버들(652, 654)은 레지스트리에 연관된 DNS 서버의 부분으로서, 혹은 이와는 별도로 동작할 수 있다.

시스템(600)은 제 1 저장장치(도시되지 않았지만, 전형적으로 랜덤 액세스 메모리, 또는 "RAM"), 제 2 저장장치(도시되지 않았지만, 전형적으로 판독전용 메모리, 또는"ROM")를 포함하는 저장 기기들에 결합되는 임의의 수의 프로세서들(도시되지 않음)을 포함한다. 이들 저장 기기들 둘 다는 위에 기술된 및/또는 언급된 임의의 적합한 유형의 컴퓨터-판독가능 매체를 포함할 수 있다. 대량 저장 기기(도시되지 않음)는 프로그램들, 데이터, 등을 저장하기 위해 사용될 수 있고, 전형적으로 주 저장장치보다는 느린 하드디스크와 같은 2차 저장 매체이다. 대량 저장 기기 내에 보유된 정보는 적합한 경우들에 주 저장장치의 부분으로서 표준적인 방법으로 가상 메모리로서 포함될 수 있음을 알 것이다. CD-ROM과 같은 특정한 대량 저장 기기는 프로세서에 일방향으로 데이터를 전달할 수도 있다.

시스템(600)은 다른 컴퓨터들(610)을 포함해서, 이를테면 비디오 모니터, 트랙 볼, 마우스(604), 키보드, 마이크로폰, 터치-감응 디스플레이, 트랜스듀서 카드 리더기, 자기 또는 종이 테이프 리더기, 타블렛, 스타일러스, 음성 또는 친필 인식기, 또는 그외 공지된 입력 기기와 같은 하나 이상의 입력/출력 기기를 포함하는 인터페이스를 포함할 수 있다.

시스템(600)은 전체적으로 601로 나타낸 바와 같이 네트워크 연결을 사용하여 컴퓨터 또는 다른 전자 통신 네트워크(690, 680)에 결합될 수 있다. 네트워크는 컴퓨터(610), 서버(650, 652, 654), 무선 통신 기기(620, 670) 및 서브-네트워크(690, 630) 간에 정보를 서로 교환하기 위해 다양한 유선, 광학, 전자 및 그외 공지된 네트워크들을 연결할 수 있다. 이러한 네트워크 연결로, 시스템(600) 및 이 내에 프로세서는 네트워크로부터 정보를 수신할 수 있거나, 위에 기술된 방법의 단계들을 수행하는 과정에서 네트워크에 정보를 출력할 수 있을 것이다. 위에 기술된 기기들 및 자료들은 컴퓨터 하드웨어 및 소프트웨어 당업자들에겐 익숙할 것이며 당업자들에 이해하게 개별적으로 속속들이 도시될 필요는 없을 것이다. 위에 기술된 하드웨어 요소들은 위에 기술된 동작들을 수행하기 위한 하나 이상의 모듈들로서 작용하게 구성될 수 있다(일반적으로 일시적으로).

또한, 본 발명의 실시예는 각종의 컴퓨터로 구현되는 동작들을 수행하기 위한 프로그램 명령들을 포함하는 컴퓨터-판독가능 저장매체를 더 포함한다. 또한 매체는 단독으로, 혹은 프로그램 명령, 데이터 파일, 데이터 구조, 테이블 등과 조합하여 포함할 수 있다. 매체 및 프로그램 명령들은 본 발명의 목적을 위해 특별히 설계되고 구성된 것들일 수 있고, 혹은 이들은 컴퓨터 소프트웨어 기술에 당업자들이 사용할 수 있는 종류의 것일 수 있다.

컴퓨터-판독가능 저장매체의 예들은 하드디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체; CD-ROM 디스크와 같은 광학매체; 플로옵티컬 디스크와 같은 자기-광학 매체; 및 프로그램 명령을 저장하고 수행하게 특별하게 구성된 판독-전용 메모리 기기(ROM) 및 랜덤 액세스 메모리(RAM)와 같은 하드웨어 기기를 포함한다. 프로그램 명령들의 예들은 이를테면 컴파일러에 의해 생성되는 기계 코드, 및 해석기를 사용하여 컴퓨터에 의해 실행될 수 있는 더 높은 레벨의 코드가 포함된 파일들을 포함한다.

발명은 예시적 실시예를 참조하여 기술되었다. 이 명세서를 읽고 이해하였을 때 당업자들에게 기술된 실시예의 수정 및 변경이 명백할 수 있다. 본 발명은 모든 이러한 수정 및 변경이 첨부된 청구항의 범위 혹은 이들의 균등범위 내에 포함되는 한 이들을 포함한다.

Claims

ⅰ)맨 왼쪽 라벨은 첫 번째 라벨이며 최고 수준 도메인은 n 번째 라벨인 마침표에 의해 분리되는 n개의 라벨을 지니는 도메인 명칭을 리졸브(resolve)하라는 요청을 권한을 지닌 명칭(name) 서버에서 수신하는 단계;
ⅱ)상기 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하는 경우 도메인 명칭을 위한 www 카운터(counter)를 증가(increment)시키는 단계;
ⅲ)상기 수신된 도메인 명칭이 오직 두개의 라벨로 이루어진 경우 도메인 명칭을 위한 정확한(exact) 카운터를 증가시키는 단계;
ⅳ)상기 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하지도 않고 오직 두개의 라벨도 아닌 경우 도메인 명칭을 위한 또 다른 카운터를 증가시키는 단계; 및
ⅴ)다수의 카운터에 근거하여 도메인 트래픽 스코어를 계산하는 단계;
로 이루어진 도메인 트래픽을 결정하는 자동화 방법에 있어서,
상기 도메인 트래픽 스코어를 계산하는 단계는 적어도 하나의 카운터에 가중치를 적용하는 단계를 포함하고,
상기 카운터는 미리 결정된 시간 당 일정 카운트로 증가가 제한되는 것임을 특징으로 하는 자동화 방법.
삭제
제 1항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인의 순위를 계산하는 단계; 및 수수료 서비스의 한 부분으로 사용자에게 상기 순위를 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.
제 1항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인 순위를 계산하는 단계; 상기 순위에 기초하여 도메인에 대한 광고료 가치를 계산하는 단계; 및 요청에 의해 광고료 가치를 사용자에게 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.
제 1항에 있어서, 상기 도메인 트래픽 스코어를 계산하는 단계는
ⅰ)하기 식에 의해 각각의 카운터를 위한 평균 일별(daily) 비율을 계산하는 단계; 및

상기 식에서 W는 www 카운터이고; E는 정확한 카운터이며; O는 또 다른 카운터이고; D는 도메인이며; P는 기간(|P|는 기간 크기의 일 수이다)이며;

SW(All, Day_i), SE(All, Day_i), 및 SO(All, Day_i)는 권한 있는 명칭서버에서 각각의 W, E, 및 O의 쿼리에 대한 개별적인 리졸버 세트의 전체 개수를 나타낸다.

ⅱ)하기 식에 따라 주어진 기간 내에서 도메인을 위한 전체 스코어를 계산하는 단계; 로 이루어짐을 특징으로 하는 자동화 방법.

상기 식에서 W_W/E/O는 W, E 및 O 각각의 타겟 유형에 대한 가중치이다.
제 5항에 있어서, W_W = 1, W_E = 0.5 및 W_O = 0.2임을 특징으로 하는 자동화 방법.
ⅰ)맨 왼쪽 라벨은 첫 번째 라벨이며 최고 수준 도메인은 n 번째 라벨인 마침표에 의해 분리되는 n개의 라벨을 지니는 도메인 명칭을 리졸브하라는 요청을 권한을 지닌 명칭 서버에서 수신하는 단계;
ⅱ)상기 수신된 도메인 명칭의 첫 번째 라벨이 스트링 "www"를 포함하는 경우 도메인 명칭을 위한 www 히트 카운터 또는 www 요청 서버 카운터 중 적어도 하나의 카운터를 증가시키는 단계;
ⅲ)상기 수신된 도메인 명칭이 오직 두개의 라벨로 이루어진 경우 도메인 명칭을 위한 정확한 히트 카운터 또는 정확한 요청 서버 카운터 중 적어도 하나의 카운터를 증가시키는 단계;
ⅳ)상기 수신된 도메인 명칭이 상기 첫 번째 라벨이 스트링 "www"를 포함하지도 않고 오직 두개의 라벨도 아닌 경우 도메인 명칭을 위한 또 다른 기타 히트 카운터 또는 또 다른 요청 서버 카운터 중 적어도 하나의 카운터를 증가시키는 단계; 및
ⅴ)다수의 카운터에 근거하여 도메인 트래픽 스코어를 계산하는 단계;
로 이루어진 도메인 트래픽을 결정하는 자동화 방법에 있어서,
상기 도메인 트래픽 스코어를 계산하는 단계는 적어도 하나의 카운터에 가중치를 적용하는 단계를 포함하고,
상기 요청 서버 카운터는 미리 결정된 시간 당 일정 카운트로 증가가 제한되는 것임을 특징으로 하는 자동화 방법.
삭제
제 7항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인의 순위를 계산하는 단계; 및 수수료 서비스의 한 부분으로 사용자에게 상기 순위를 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.
제 7항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인 순위를 계산하는 단계; 상기 순위에 기초하여 도메인에 대한 광고료 가치를 계산하는 단계; 및 요청에 의해 광고료 가치를 사용자에게 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.
제 7항에 있어서, 상기 도메인 트래픽 스코어를 계산하는 단계는
ⅰ)하기 식에 의해 카운터 각각에 대해 평균 일별 비율을 계산하는 단계; 및

상기 식에서 W는 www 카운터이고; E는 정확한 카운터이며; O는 또 다른 카운터이고; D는 도메인이며; P는 기간(|P|는 기간 크기의 일 수이다)이며;

SW(All, Day_i), SE(All, Day_i), 및 SO(All, Day_i)는 권한 있는 명칭서버에서 각각의 W, E, 및 O의 쿼리에 대한 개별적인 리졸버 세트의 전체 개수이다.

ⅱ)하기 식에 따라 주어진 기간 내에서 도메인에 대한 전체 스코어를 계산하는 단계; 로 이루어짐을 특징으로 하는 자동화 방법.

W_W/E/O는 W, E 및 O 각각의 타겟 유형에 대한 가중치이다.
제 11항에 있어서, W_W = 1, W_E = 0.5 및 W_O = 0.2 임을 특징으로 하는 자동화 방법.
ⅰ)맨 왼쪽 라벨은 첫 번째 라벨이며 최고 수준 도메인은 n 번째 라벨인 적어도 두 개는 마침표에 의해 분리되는 상이한 수의 라벨을 지닌 도메인 명칭을 리졸브하라는 다수의 요청을 권한을 지닌 명칭서버에서 수신하는 단계;
ⅱ)상이한 수의 라벨을 지닌 적어도 두 개의 요청을 별개로 카운트하는 적어도 두 개의 카운터에 다수의 요청에 근거하여 다수의 카운터를 증가시키는 단계; 및
ⅲ)다수의 카운터에 근거하여 도메인 트래픽 스코어를 계산하는 단계;
로 이루어진 도메인 트래픽을 결정하기 위한 자동화 방법에 있어서,
상기 도메인 트래픽 스코어를 계산하는 단계는 다수의 카운터 중 적어도 하나에 가중치를 적용하는 단계를 포함하고,
상기 다수의 카운터 중 적어도 하나의 카운터는 미리 결정된 시간 당 일정 카운트로 증가가 제한되는 것임을 특징으로 하는 자동화 방법.
삭제
제 13항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인의 순위를 계산하는 단계; 및 수수료 서비스의 한 부분으로 사용자에게 상기 순위를 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.
제 13항에 있어서, 상기 자동화 방법은 도메인 명칭에 상응하는 도메인 순위를 계산하는 단계; 상기 순위에 기초하여 도메인에 대한 광고료 가치를 계산하는 단계; 및 요청에 의해 광고료 가치를 사용자에게 제공하는 단계; 를 더욱 포함함을 특징으로 하는 자동화 방법.