KR20090043561A

KR20090043561A - 내비게이션 기기에서의 사용을 위한 개선된 맵 데이터를 생성하는 방법 및 개선된 맵 데이터를 가진 내비게이션 기기

Info

Publication number: KR20090043561A
Application number: KR1020097005201A
Authority: KR
Inventors: 피터르 헤일런; 로리 존스; 마레이예 루센; 게이르트 힐브란디
Original assignee: 톰톰 인터내셔날 비.브이.
Priority date: 2006-08-15
Filing date: 2007-08-15
Publication date: 2009-05-06
Also published as: AU2007286430A1; TW200827676A; EP2327961A3; CN103940437B; JP2010500587A; EP2052209A2; KR20090041431A; WO2008019879A2; US8407003B2; EP2052210A1; JP2014055962A; TW200823431A; US7873465B2; TWI417521B; WO2008019880A1; US20080059055A1; RU2009109241A; JP2017016135A; TW200817933A; AU2007286428A1

Abstract

엔드유저는 기기 상에서 직접, 맵 오류에 대한 정정을 입력할 수 있다. 그러면 그 기기는 그 정정에 관한 외부 프로세싱 없이 그 정정을 사용할 수 있다. 따라서, 엔드유저가 웹 링크를 통해 맵 공급자에게 오류들을 단순하게 보고하고, 그리고 나서 그 맵 공급자가 그 오류를 검증하고, 그 맵들을 업데이트하며 마지막으로 엔드유저에게 업데이트들을 공급하기를 기다리는 것 - 완성하기 위해 수 개월 및 때때로 수 년이 걸릴 수 있는 시간 - 이 더 이상 필요하지 않다. 대신에, 그 내비게이션 기기는 그 정정을 즉각적으로 사용할 수 있다. 엔드유저들은 또한, 정정들을 모으고 타당성확인하고 배포하는 공유 원격 서버와도 그리고 다른 엔드유저들과도 정정들을 공유할 수 있다.

Description

내비게이션 기기에서의 사용을 위한 개선된 맵 데이터를 생성하는 방법 및 개선된 맵 데이터를 가진 내비게이션 기기{A method of generating improved map data for use in navigation devices and a navigation device with improved map data}

본 발명은 내비게이션 기기들에서 사용하기 위한 개선된 맵 데이터를 생성하는 방법에 관한 것이다. 내비게이션 기기들은 GPS 기반의 전자적인 개인 내비게이션 기기들을 포함한다.

전자 내비게이션 기기들, 예컨대 TomTom International BV의 GO^TM와 같은 GPS 기반 개인 내비게이션 기기들을 위한 맵 데이터는, Tele Atlas NV와 같은 전문적인 맵 공급자들로부터 나온다. 이 맵 데이터는, 전형적으로 GPS 시스템으로부터 위치 데이터를 사용하여, 경로 안내 알고리즘(route guidance algorithm)들에 의해 사용되기 위해 특별히 설계된다. 예를 들어, 도로들은 선들 - 즉 벡터들 (예: 시작점, 끝점, 도로 방향으로, 전체 도로는 각각이 시작점/끝점 방향 파라미터들에 의해 고유하게 정의되는 몇백 개의 이러한 부분들로 구성된다)로서 묘사될 수 있다. 그때 맵은 이러한 도로 벡터들, 각 벡터와 연관된 데이터(속도 제한; 진행 방향 등)와 관심대상 지점(point of interest;POI)들, 도로 이름들, 공원 경계, 강 경계 등과 같은 다른 지리적 특징(feature)들의 집합이고, 이것들 모두는 벡터로 정의된다. 모든 맵 특징(map feature)들(예: 도로 벡터, POI 등)은 전형적으로 GPS 좌표 시스템과 대응되는 또는 그것에 관련된 좌표 시스템에서 정의되어, GPS 시스템을 통해 결정되어진 기기 위치를 맵에서 보여지는 관련 도로 상에 위치하게 하고 최적의 경로가 목적지를 향해 계획되는 것을 가능하게 한다.

이 맵 데이터베이스를 구성하기 위해, Tele Atlas는, 영국의 도로들에 대한 Ordnance Survey와 같은 다양한 소스들로부터 기초적 도로 정보로 시작한다. 그것은 또한, 도로들 상에서 운행하는 차량들과 다른 맵들을 조사하는 직원들, 및 항공 사진들로 이루어진 큰 전용 팀을 가지고 있어서 그 데이터를 업데이트하고 조사한다. 이 데이터는 Tele Atlas 맵 데이터베이스의 핵심을 구성한다. 이 맵 데이터베이스는 지리적기준(geo-referenced) 데이터로써 계속적으로 증대되어지고 있다. 그래서 그것은 조사되고 TomTom과 같은 기기 제조자들에게 1년에 4번 발행된다.

이들 맵들을 업데이트하고 검증하는 것을 행하는 방대한 자원(resource)들에도 불구하고, 어떤 지리적 지역들에 대한 데이터는 1년 또는 그 이상 지난 것일 수도 있다.

상기에서 기술된 계속되고 있는 개선들에 더하여, 엔드유저(end-user)들은 Tele Atlas의 웹 사이트를 사용하여 Tele Atlas에 대해 맵 오류(map error)들을 직접 보고할 수 있다. TomTom과 같은 기기 제조자들은 또한 이러한 방식으로 그들 사용자들로부터의 맵 오류 보고들을 포착하고 전송한다. 이들 오류 보고들은 일반적 으로 단지 자유로운 텍스트 포맷이어서, 그 오류가 실제로 의미하는 것 및 그것들이 관련된 어느 정확한 위치를 파악하는데 상당한 노력을 들여야 한다. 일단 진짜 오류로서 검증된다면, 적절한 정정이 확인(validate)되고 그리고 나서 차후의 맵 릴리즈(release)에 포함된다. 결국 그 정정은 최초로 알려진 후 1년 또는 그 이상 지나 엔드유저 기기에서 인지되거나 또는, 어떤 경우들에 있어서는, 전혀 인지되지 않을 수도 있다.

또한, GPS 위성 내비게이션 기기를 사용하여 계획되고 완성된 여행의 '자취'(trace)를 저장하는 것이 알려져 있다 (예를 들어, 미국 프린스톤(Princeton)에 있는 ALK Technologies에 의해 제공된 'GPS track submission' 기능을 참조). 이 자취는, 지오코딩된(geo-coded) 데이터를 사용하여, 차량이 얻은 완전한 경로에 관한 기록이다. 그때 사용자는 이 자취 데이터를 그 기기 공급자에게 다시 보낼 수 있고; 그 후에 그것은 맵 데이터베이스의 정확성 및 완전성을 향상시키는데 사용된다. 예를 들면, 도로 또는 모퉁이(turning)에 관한 정확한 위치는 기기에 의해 사용되는 맵 상에서 정확하게 포착되지 않을 수도 있고; 그 도로 또는 모퉁이를 가는 사람을 위한 집합적인 트랙(track)들이 더 정확한 위치가 결정되는 것을 가능하게 할 것이며; 그 기기 공급자에 의한 차후의 맵 릴리즈들은 정정을 통합시킬 수 있다.

또한, 종종 '위키맵들'(wikimaps)로 불리는 협력적 맵핑 프로젝트(mapping project)들에 관하여 언급할 수도 있다. 그러나 위키맵들은 우리가 정의하는 것으로서의 '맵 데이터' - 즉, 목적지로의 도로 시스템 상의 경로를 작성하는 경로 안 내 알고리즘들에 적합한 맵 데이터 - 를 생성하지 않는다.

본 발명은 내비게이션 기기들에서 사용하기 위한 개선된 맵 데이터를 생성하는 방법이고, 상기 방법은 다음의 단계들을 포함한다:

a) 전자 내비게이션 기기 상에, 경로 안내 알고리즘들에 적합한, 맵 데이터를 디스플레이하는 단계;

b) 상기 기기의 엔드유저가, 직접 상기 기기 상에, 맵 오류(map error)에 대한 정정(correction)을 입력하는 단계;

c) 상기 기기가 상기 정정에 관한 외부 프로세싱 없이 상기 정정을 사용할 수 있는 단계.

따라서, 엔드유저가 웹 링크(web link)를 통해 맵 공급자에게 오류들을 보고하는 것, 그래서 그 맵 공급자가 그 오류를 검증하고, 그 맵들을 업데이트하며 그 업데이트를 공급하는 것을 기다리는 것 - 완성하기 위해 수 개월 및 때때로 수 년이 걸릴 수도 있는 시간 - 에 한정되어지는 것이 더 이상 필요하지 않다. 대신에, 내비게이션 기기가 외부 프로세싱 - 예: 맵 공급자에 의한 검증 - 없이 그 정정을 사용할 수 있다. 기기에 의한 정정의 이용은, 상대적인 용어로, '즉각적'(immediate)일 수 있다. '즉각적'이라는 용어는 즉시로서가 아니라 단순히 그 정정이 입력된 후에 '곧'을 의미하는 것으로서 해석되어야 할 것이다. 사용자가 그 정정이 사용되어야 하는지를 검증하고, 그 기기를 켜고 그리고 나서 끄는 것 등과 같은 개입 단계들이 있을 수 있다.

구현에 있어서, 사용자들이 그들의 기기 상에 저장된 맵 데이터에 수정을 하는 것을 허용하는 내비게이션 기기가 있다. 그 내비게이션 기기는 TomTom International BV의 GO 시리즈 기기와 같은 경로 안내 능력을 가진 휴대용 독립형 GPS 내비게이션 기기, 또는 모바일 전화기나 PDA와 같은 임의의 다른 종류의 휴대용 정보 기기일 수 있다. 그러나 동등하게, 그것은 차량에 통합된 기기, 또는 내비게이션 소프트웨어(이 용어는, 실제로 동적인 경로 안내가 아니고 대신에 단순히 맵핑 - 사용자가 어디에 있는지 - 을 전달하는 맵핑 소프트웨어를 포함한다. 또한, 그 내비게이션 소프트웨어는 클라이언트 기기 상에서 로컬로 실행되거나 또는 클라이언트 기기로부터 원격의 서버 상에서 실행될 수 있다)를 실행시키는 고정식 데스크탑(desktop) PC(랩탑(laptop) 포함)와 같은 컴퓨팅 기기일 수 있다. 그때 PC는 경로 안내 능력을 가진 휴대용 내비게이션 기기와 도킹(docking)될 수 있고 그 휴대용 내비게이션 기기에 정정들을 전송할 수 있다.

이러한 내비게이션 기기의 전형적인 특징들은 다음과 같다:

● 사용자가 디지털로 저장된 맵에 대한 정정들을 생성할 수 있게 해 주는 사용자 인터페이스;

● 사용자가 경로 계산들에서 맵 정정들을 포함하거나 배제할 수 있게 해 주는 사용자 인터페이스;

● 사용자가 디지털 맵 상에 그의 정정된 맵 데이터를 볼 수 있게 해 주는 사용자 인터페이스;

● 사용자가 하나 이상의 운송 유형들과 맵 정정들을 연관시킬 수 있게 해 주는 정정 카테고리들의 집합;

● 예를 들어 콘텐트 모음 서비스(content aggregation service)를 거쳐, 다른 사용자들과 맵 정정들을 공유할 수 있는 능력. 공유된 맵들은 그것들이 다운로드되자마자 (예: 경로 계획 알고리즘 또는 맵 디스플레이 엔진(map display engine)에 의해) 사용하기에 유효하다.

본 발명의 제2 측면은 자동화된 맵 정정 제안 방법이다: 이 방법에서, 내비게이션 기기는 운전자 행동에 관련된 통계 데이터를 수집하고 분석하며, 전형적으로 일정 문턱 기준들(threshold criteria)이 충족될 때, 사용자에게 맵 정정들을 제안한다. 예를 들면, 만약 사용자가 그 기기가 아래로 경로를 계획했던 도로로 들어가지 않았다면, 그것은 실제 도로가 '출입 금지' 표시를 가지고 있지만, 그 기기 상에 저장된 맵이 최신이 아니기 때문일 수도 있다. 그러면 그 기기는 '미안하지만, 그 맵은 부정확하였습니까?'와 같은 메시지를 그 메시지에 의해 디스플레이된 '예' 및 '아니오' 버튼들과 함께 자동적으로 디스플레이할 수 있다. 만약 사용자가 '예'를 누르면, 그러면 그 기기는 사용자가 그 기기 상에 저장된 맵에 대한 정정들을 생성할 수 있게 해 주도록 사용자 인터페이스를 디스플레이할 수도 있다. 그리고 나서 사용자는 '출입 금지' 도로로서 그 도로를 마킹(marking)함으로써 그 맵을 정정할 수 있다. 그 정정은 그 내비게이션 기기 상에서 실행되는 경로 계획 알고리즘들에 관해 즉각적으로 이용가능하다.

제3 측면은 맵 정정 분석 방법이다: 이 방법에서, 시스템은 다음 중 하나 이상을 사용하여 맵 정정들을 분석한다:

● 정정의 "타당성"(validity)을 얻기 위해 사용자 정정들에 관한 분석 및 모음;

● 단일의 사용자로부터의 정정들의 "신뢰성"(trustworthiness)을 얻기 위해 그 단일의 사용자에 의해 공급되는 정정들에 관한 분석;

● "금지된"(banned) 단어들(예: 거리 이름들에서의 허사(expletive)들)을 제거하기 위해 모든 문자열 데이터(string data)에 관한 키워드 분석;

● 맵 정정이 동일한 영역에 관한 다른 맵들(다른 공급자들로부터의 맵들 및 같은 공급자로부터의 더 새로운 버전들의 맵 양자 모두 해당)에 적용되어야 하는지 여부를 결정하기 위해 정정들에 관한 분석.

본 발명은 첨부된 도면들을 참조하여 기술될 것이고, 그 첨부된 도면들에서,

도 1은 내비게이션 기기에 의해 디스플레이된 주요 오류 보고를 위한 화면이고;

도 2는 사용자들이 포착하고 보고하기를 바라는 오류 유형을 사용자들이 정의할 수 있게 해주는 화면을 보여주는 도면이고;

도 3은 본 발명을 구현하는 내비게이션 기기로부터의 스크린 샷(screen shot)으로, 그 스크린 샷은 도해된 맵 뷰(map view) 및 디스플레이의 하단부를 따라 실행되는 상태 바(status bar)를 보여주고;

도 4는 3-D 도를 구현하는 내비게이션 기기로부터의 스크린 샷이고;

도 5는 내비게이션 메뉴를 보여주고 있는 내비게이션 기기로부터의 스크린 샷이고;

도 6a 및 도 6b는 내비게이션 기기의 원근도들이고;

도 7은 내비게이션 기기의 시스템 구조에 관한 도식적인 도면이고;

도 8은 내비게이션 기기에서의 콤포넌트들에 관한 블록 다이어그램(block diagram)이고; 그리고

도 9는 도 8의 내비게이션 기기에서의 전기적 하위 부품들에 관한 다이어그램이다.

본 발명은 Map Share^TM로 불리는 구현을 참조하여 기술될 것이다. Map Share는 사용자들이 TomTom International B.V의 GO 개인 내비게이션 기기들을 사용하여 맵 오류들을 정정하고 또한 공유하고 보고할 수 있게 해 줄 것이다. 사용자는 내비게이션 기기 내에 정정(또는 맵 정정)을 기입한다. 그 후 그 맵 정정은 도로들, POI들 등에 관해 경로를 정하고 디스플레이하는 데에 그 기기에 의해 사용되는 맵 데이터를 보충하기 위해 그 기기에 로컬로 적용된다. 그 맵 정정은 즉각적으로 이용가능하다. 그 맵 정정은 다수의 방식들로 그 기기에 의해 TomTom 서버에 보고될 수 있다: 그 기기는 필수적인 통신 능력(예: 그 서버에 데이터를 보낼 수 있는 무선 셀룰러 시스템)을 가질 수도 있거나, 데이터를 그 서버로 송신할 모바일 전화에 단거리 무선 링크를 통해 그 데이터를 송신할 수도 있거나, 그 서버와 통신할 수 있는 인터넷 연결 PC와 도킹할 수도 있으며, 또는 그 자체가 그 인터넷 연결 PC일 수도 있다. 그때 그 서버는 모든 사용자들로부터 모든 정정들을 모으고, 정정들의 타당성을 확인하고, 그리고 그 정정들을 다른 사용자들에게 배포하며, 그리고 하나 이상의 맵 공급자들과 그 정정들을 공유할 수 있다.

완전히 구현되어질 때, 이 피드백(feedback)은 TomTom 제품들에서 맵 데이터를 업데이트하는 주된 메커니즘으로서 맵 공급자 업데이트들을 대체할 수 있다.

Map Share에 관한 하나의 구현 영역은 사용자에게 친근한, 기기상 도구(on-device tool)들을 제공하는 것으로, 여기서 그 기기상 도구들은 그 사용자로 하여금:

● 그들 맵 상의 거리들을 블록하고(block) 언블록(un-block)하도록

● 그들 맵 상의 거리들의 교통 방향을 수정하도록

● 그들 맵 상의 거리 이름들을 추가하고 수정하도록

● 그들 맵 상의 도로들의 속도 제한들을 수정하도록

할 수 있게 해 주는 것이다.

따라서, 그 정정들은 경로지정 계산 알고리즘들이 어떻게 작동되는지에 직접 영향을 끼친다 - 즉, 그것들은 목적지로의 경로를 계산할 때 사용된다. Map Share는 또한 사용자로 하여금:

● 그 맵에 안전 카메라 위치(safety camera location)들을 추가하도록

● 다른 사용자들과 맵 정정들을 공유하도록

● 다른 사용자들로부터 맵 정정들을 다운로드하도록

● 많은 오류들에 대한 맵 오류 보고들을 생성하도록

할 수 있게 해 준다.

기기상의 정정들에 더하여, 모든 상기의 정정 유형들에 대한 같은 정정 특징들이, 예를 들어 정정들을 저장하기 위하여, 그 기기에 연결할 수 있는 데스크탑 컴퓨터 어플리케이션을 사용하여 이용가능하게 될 수 있다.

기기상의 특징들에 더하여, 현존하는 TomTom 맵 오류 보고 도구에 대한 개선들이 가능하고, 여기서 그 도구는 웹 기반이다:

● 맵 오류 보고는 톰톰 지원 웹사이트(TomTom Support Website) 내에서 발견하기에 더 용이하게 될 것임

● 맵 오류 보고 도구들은 TomTomHome 어플리케이션에 추가될 것임

● 사용자들은 그들이 보고하였던 맵 오류들에 대한 피드백을 수신할 것임

● TomTom은 그것의 맵 공급자, 예를 들어 TeleAtlas에게 오류들을 보내기 전에 그 오류들을 미리 우선순위화할 수 있을 것임.

이전에 설명한 바와 같이, Map Share 구현에서의 중요한 특징들은:

● 맵 정정들, 오류 보고 등을 그 기기 상에서 하는 것

● 일정한 정정들이 즉각적인 효과를 나타내게 만드는 것(예: 사용자-정의 기준들을 충족시키는 것들)

● 사용자들이 다른 사용자들과 정정들을 교환할 수 있게 해 주는 것이다.

GO 내비게이션 기기에 관하여, 이것은 도 1a에 보여지는 바와 같이, 'Make changes to the map'인 메뉴 항목을 디스플레이하는 기기에 의해 구현될 수 있다. 이 항목을 선택한 결과는 아래에서 논의된다. 먼저 기술될 2개의 추가적인 메뉴 항 목들이 있다.

첫 번째로, 'Exchange Changes'인 메뉴 항목은 사용자로 하여금, 사용자 자신의 변화들에 관한 업로드를 개시하고 다른 사람들의 변경들을 그 기기에 다운로드할 수 있게 해준다. 업로드는 GO 기기가 도킹되어진 인터넷 연결 PC를 거쳐 또는 블루투스(Bluetooth) 네트워크를 통해 GO 기기에 연결하는 GPRS 무선 링크를 가진 모바일 전화를 거칠 수 있다.

두 번째로, 'Preferences About changes'인 메뉴 항목은 어느 변경들을 허용할지를 결정한다. 이 항목을 선택함으로써 그 기기로 하여금, 허용할 적용가능한 유형의 변경들을 사용자가 표시할 수 있는 체크 박스들과 함께, 메뉴 화면을 디스플레이하게 할 수 있다.

어떤 변경들이 허용되어야 하는지는 다음과 같을 것이다:

[x] 당신의 독자적인 변경

[x] 최근의 변경

[ ] 지난 해의 변경 / 다른 맵들 상에서 이루어진 것

[x] 한 번 이상 보고된 경우만

[x] 믿을 수 있는 소스들로부터인 경우만

2635개 중 1365개의 이용가능 변경들이 허용됨.

만일 사용자가 'Make changes to map' 아이콘을 그것을 누름으로써 선택한다면, 그것은, 그 맵을 변경할 즉효(INSTANT-EFFECT) 옵션들과 이에 더하여 오류를 보고(REPORT)할 옵션(만약 그 오류가 자가활동(self-action)으로써 커버되지 않는 경우)을 제공하는 서브메뉴로 사용자를 이끈다. 이것들은, 도 1b에서 보여지는 바와 같이, 다음을 포함한다:

● Add/change street name(거리 이름 추가/변경): 만약 사용자가 이것을 선택하면, 그때는 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) 거리들의 이름들에 관한 리스트를 디스플레이할 수 있다; 사용자는 이름을 바꿀 거리를 선택할 수 있고 그리고 나서 화면상의 키보드(on-screen keyboard)를 통해 새로운 이름을 기입할 수 있다.

● Block Street(거리를 블록): 만약 사용자가 이것을 선택하면, 그때는 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) 거리들의 이름들에 관한 리스트를 디스플레이할 수 있다; 사용자는 블록될 거리를 선택할 수 있다.

● Change traffic direction(교통 방향 변경)(미도시): 만약 사용자가 이것을 선택하면, 그때는 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) 거리들의 이름들에 관한 리스트를 교통 방향과 함께 디스플레이할 수 있다; 사용자는 교통 방향이 변경되어질 거리를 선택할 수 있다.

● Change speed limit(속도 제한 변경): 만약 사용자가 이것을 선택하면, 그때는 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) 거리들의 이름들에 관한 리스트를, 적용가능한 속도 제한들과 함께, 디스플레이할 수 있다; 사용자는 속도 제한이 변경되어질 거리를 선택하고 그리고 나서 메뉴로부터 적절한 새로운 속도 제한을 선택할 수 있다.

● Un-block street(거리를 언블록): 만약 사용자가 이것을 선택하면, 그때는 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) 블록된 거리들의 이름들에 관한 리스트를 디스플레이할 수 있다; 사용자는 언블록될 거리를 선택할 수 있다.

게다가, 'Edit/delete POI'(POI 편집/삭제) 아이콘을 선택하여 다음 사항들을 위한 그래픽 옵션들을 가진 더 아래의 하위메뉴에 도달하는 것이 가능하다:

- Rename a POI: POI 이름 변경

- Move a POI: POI 이동

- Add a POI to a category: 카테고리에 POI 추가

- Delete a POI: POI 삭제

- Re-categorize a POI: POI 재분류.

각각의 경우에, 그 기기는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 기기가 정상 내비게이션 모드에 있다면 디스플레이될) POI들의 이름들에 관한 리스트를 디스플레이할 수 있다; 사용자는 관련 POI를 선택하고 그리고 나서 그 POI를 편집하거나 삭제할 수 있다. 이들 POI들은 전형적으로 맵 공급자에 의해 공급된 것들이지만, 사용자에 의해 다운로드된 POI들을 포함할 수 있다(예: 속도 카메라들).

추가적인 메뉴 항목은 'Report other error'(다른 오류를 보고)하는 것이다. 이것은 불편사항(complaint)들, 빠진 도로들 등이 보고될 수 있게 한다. 전형적인 기능들은 사용자로 하여금 위치를 고르고, 전형적인 이슈(issue)들의 리스트에서 선택할 수 있게 하고 사용자로 하여금 자유로운 텍스트 설명 등을 추가할 수 있게 해 주는 것이다.

- 다른 특징들

● 사용자들은 그들 맵에 대한 "사적"(private) 정정들 및 또한 집적을 위하여 TomTom에 보내지는 "공유"(shared) 정정들을 생성할 수 있다.

● 각 맵 정정은 독립적으로 저장된다.

● 모든 맵 정정들은 OTA(Over-The-Air) 배포를 위해 고도로 압축가능하다.

● 모든 맵 정정들은, 경쟁자들이 TomTom 기기들 상에 이루어진 정정들을 사용하여 그들 자신의 맵들을 정정할 수 없음을 확실히 하기 위하여 고도의(HIGHLY) 보안(그 포맷을 수동으로 리버스 엔지니어링(reverse engineering)하는 것이 가능하지 않도록 함)을 갖춘다.

● 정정들은 맵에 독립적인 형태로 저장된다.

▶ 맵 정정들은 맵 업그레이드 동안 유지보존된다.

▶ 맵 정정들은 서로 다른 공급자들로부터의 맵들에 적용될 수 있다.

● 만약 정정에 관련된 지역이 맵 데이터의 새 릴리즈에서 변경되었다면 맵 정정들은 자동적으로 제거될 수 있다(이 경우에서 우리는 맵 오류가 맵 공급자에 의해 정정되어졌다는 것을 가정하기 때문)

● 맵 정정들은 사용자의 맵 데이터를 영구히 수정하지 않는다.

● 사용자들은 어떤 종류의 변경들을 그들이 사용할지를 선택할 수 있다(예: "나의 변경들만을 사용" 또는 "나의 변경들 및 TomTom으로부터의 변경들을 사용")

● TomTom은 각각의 릴리즈된 맵 버전에 대한 맵 정정 데이터베이스들을 유지한다 (주의: 새 맵들을 가진 사용자들은 더 오래된 맵들 상에서 보고된 정정들을 받을 수 있지만, 오래된 맵들의 사용자들은 더 새로운 맵들 상에서 보고된 정정들을 수신할 수 없을 것이다).

● TomTom은 맵 정정들 및 보고들이 수집되어지고 다른 사용자들과 공유될 수 있도록 모음 시스템(aggregation system)을 생성한다.

● TomTom은 맵 정정들 및 보고들의 타당성 또는 신용성이 평가될 수 있도록 "신용"(trust) 시스템을 생성한다. 정기적으로 좋은 오류들을 보고하는 사용자들은 "신뢰받는"(trusted) 자들로 될 수도 있고, 그들의 정정들은 타당성확인할 필요 없이 모든 사용자들에게 제공된다. 이들 사용자들은 또한 다른 사용자들에 의해 제출된 정정들의 타당성을 확인할 것을 요구받을 수도 있다.

● TomTom은 사용자들에 의해 보내진 정정들을 보증한다(endorse) (일단 그r것들이 타당성확인되었을 경우).

도 2는 본 발명을 구현하는 내비게이션 기기에 탑재되는 핵심 소프트웨어 모듈들을 도식적으로 보여주고 있다. 디스플레이(21)는 기존의 방식으로 사용자가 목적지 주소를 기입하는 터치 스크린 디스플레이이다. 그 주소 데이터 입력은 UI 모듈(22)에 의해 다루어지고 내비게이션/경로 계획 모듈(23)로 송신된다. GPS 모 듈(24)로부터 GPS 피드(feed)를 얻는 경로 계획 모듈(23)은 그 기기가 가지고 있던 (또는 그렇지 않으면 Tele Atlas와 같은 맵 공급자로부터 공급된) 암호화되고, 압축된 맵 데이터로부터 맵 데이터를 사용하여 경로를 계획한다. 그때 본 발명은 다음과 같이 구현된다: 사용자는 필요하면, 도 1a 및 도 1b에 의해 예시하고 있는 바와 같이, 터치 스크린 상호작용을 활용하고, 큰 그래픽 아이콘들을 터치하여, 맵 정정을 디스플레이(21)에 기입한다. UI 모듈(22)은 그 맵 정정을 포착하고 그것을 맵 정정 저장소(26)로 보낸다. 맵 정정이 맵 정정 저장소(26)에 있게 되자마자, 그것은 경로 계획 모듈(22) 및 UI 모듈(22)에 대해 이용가능하게 된다. 만약 그 맵 정정이, 운행되어지는 현재의 경로도 재계획할 것을 필요로 한다면, 그때 그것은 자동적으로 일어날 것이다 (만약 그 사용자가 그 옵션을 설정한 경우). 예를 들면, 그 기기는 사용자가 거리로 진입(회전)할 것을 필요로 하는 경로를 계획할 수도 있다: 그 진입(회전)에 도달할 때, 사용자는 그것이 최근에 '출입 금지' 거리로 되었음을 발견한다. 사용자는 적절한 맵 정정을 기입할 수 있다: 그때 그 출입 금지 거리를 고려하여 새로운 경로가 즉각적으로 계획되고 적절한 경로 안내가 주어진다. 마찬가지로, 만약 사용자가 다른 목적지로의 완전히 새로운 경로를 계획한다면, 그 새로운 경로도 또한 그 맵 정정을 고려할 것이다. 만약 그 맵 정정이 어떻게 그 맵이 나타나야할지(예를 들면, 도로의 이름을 변경하는 것, 새로운 POI를 보여주는 것, 예컨대 속도 카메라)에 작용하여야 한다면, 그때는 그 새로운 모습이 즉각적으로 나타날 것이다. 정정을 자동적으로 사용하는 것은 의무적인 것은 아니고; 어떤 사용자들은 맵 정정들을 배제하는 경로 계산 등을 선호할 수도 있다.

부록 1은 본 발명을 구현할 수 있는 전형적인 기기를 묘사한다. 부록 2는 Map Share에 대한 고수준의 요구조건들이다.

- 부록 1

본 발명은 GO로 불리는 TomTom B.V.의 통합 내비게이션 기기로 구현될 수 있다. GO는 Navigator(또는 Navcore)로 불리는 내비게이션 소프트웨어를 탑재하고 내부 GPS 수신기를 가진다; Navigator 소프트웨어는 또한 컴팩(Compaq) iPaq과 같은 터치 스크린(즉 스타일러스(stylus) 제어) 방식의 포켓(Pocket) PC 전원의 PDA 기기 상에서 실행될 수 있다. 그러면 그것은 그 PDA가 GPS 수신기와 결합될 때 GPS 기반 내비게이션 시스템을 제공한다. 결합된 PDA 및 GPS 수신기 시스템은 차량내 내비게이션 시스템으로서 사용되도록 설계된다.

본 발명은 또한 임의의 다른 구성의 내비게이션 기기, 예컨대 통합된 GPS 수신기/컴퓨터/디스플레이를 가진 기기, 또는 비차량에서 사용하기 위해(예: 보행자들을 위해) 설계되거나 차와 다른 운송수단들(예: 항공기)을 위해 설계된 기기로 구현될 수도 있다. 그 내비게이션 기기는 임의의 종류의 위치 센싱 기술을 구현할 수도 있고 GPS에 제한되지는 않는다; 따라서 그것은 다른 종류의 European Galileo 시스템과 같은 GNSS(global navigation satellite system)를 사용하여 구현될 수 있다. 동등하게, 그것은 위성 기반 위치/속도 시스템들에 제한되지 않지만, 그라운드기반 비콘(ground-based beacon)들이나 그 기기가 그 기기의 지리적 위치를 결정하는 것을 가능하게 하는 임의의 다른 종류의 시스템을 사용하여 배치될 수 있다.

Navigator 소프트웨어는, PDA 상에서 실행될 때, 도 3의 정상 내비게이션 모 드 화면이 디스플레이되게 하는 내비게이션 기기를 결과적으로 도출한다. 이 뷰는 텍스트, 기호, 음성 안내 및 이동 맵(moving map)의 조합을 사용하여 운전 지시들을 제공한다. 본질적인 사용자 인터페이스 요소들은 다음과 같다: 2-D 맵(1)은 화면의 대부분을 차지한다. 그 맵은 사용자의 차 및 그것의 인접한 주변을 보여주고, 차가 이동하고 있는 방향이 항상 "위쪽"이 되는 식으로 회전된다. 화면의 하부 1/4에 상태바(2)가 걸쳐 있다. 그 기기 자체적으로 기존의 GPS 위치 발견을 사용하여 결정한 것으로서의 그 기기의 현재 위치 및 그것의 지향(orientation)(그것의 진행 방향으로부터 추론됨)이 화살표(3)에 의해 묘사된다. 그 기기에 의해 계산된 경로(기기 메모리 내 맵 데이터베이스에 저장된 맵 데이터에 적용되는 것으로서 기기 메모리에 저장된 경로 계산 알고리즘들을 이용)는 진행 방향을 부여하는 화살표들로 중첩된 어두운 길(4)로서 보여진다. 어두운 길(4) 위에, 모든 주요 액션(action)들(예: 회전 코너, 교차로, 로터리 등)이 길(4)에 그려진 화살표들(5)로써 도식적으로 묘사된다. 상태 바(2)는 또한 그것의 좌측에 다음 액션(여기서는, 우회전)을 묘사하는 개략도(6)를 포함한다. 상태 바(2)는 또한 그 기기에 의해 계산된 전체 경로에 관한 데이터베이스(즉 취해질 경로를 정의하는 모든 도로들 및 관련 액션들의 리스트)로부터 추출되어진 다음 액션에 대한 거리(즉 우회전 - 여기서 거리는 220 미터)를 보여준다. 상태 바(2)는 또한 현재 도로의 이름(8), 도착까지의 추정 시간(9)(여기서는 2분 40초), 실제 추정되는 도착 시간(10)(오전 11시 36분) 및 목적지까지의 거리(11)(1.4km)를 보여준다. GPS 신호 세기는 모바일 전화 양식의 신호 세기 표시자(12)로 보여진다. 도 4에서 보여지는 바와 같이, 3-D 맵 뷰(map view)도 또한 가능하다.

만약 사용자가 스크린(13)을 터치하면, 그때 내비게이션 화면의 주 메뉴(미도시)가 디스플레이된다; 이 메뉴로부터, Navigator 어플리케이션 내의 다른 핵심 내비게이션 기능들이 개시되거나 제어될 수 있다. 핵심 내비게이션 기능들이, 자체적으로 매우 쉽게 호출된 메뉴 화면(예: 맵 디스플레이에서 메뉴 화면까지 한 단계 떨어져 있음)으로부터, 선택될 수 있게 하는 것은, 사용자 상호작용을 크게 단순화시키고 그것을 더 빠르고 더 용이하게 한다.

사용자에 의해 터치될 것을 필요로 하는 터치 존(touch zone) 영역은 대부분의 스타일러스 기반 터치 스크린 시스템들에서보다 훨씬 더 크다. 그것은, 특별한 정밀함을 갖추지 않은 하나의 손가락에 의해 확실하게 선택될 만큼 충분히 크게 설계된다; 즉, 차량을 제어할 때 운전자의 현실 상태조건들과 유사하게 하기 위해 그렇게 설계된다; 운전자는 작은 제어 아이콘들을 가진 고도로 상세한 화면을 볼 시간이 별로 없을 것이고, 그들 작은 제어 아이콘들 중 하나를 정확하게 누를 시간은 더 없을 것이다. 따라서, 주어진 소프트 키(soft key)(또는 스크린(13)의 중심에서와 같은, 숨겨진 소프트 키)와 연관된 매우 큰 터치 스크린 영역을 사용하는 것은 이 구현의 사려 깊은 설계 특징이다. 다른 스타일러스 기반 어플리케이션들과 달리, 이 설계 특징은, 운전자가 실제로 운전하고 있는 동안 운전자가 필요로 할 것 같은 핵심 기능들을 선택하도록 Navigator의 도처에 일관되게 배치된다. 따라서, 사용자에게 화면상의 아이콘들(예: 예를 들어 목적지 주소를 기입하기 위한 가상 키보드(virtual keyboard)의 키들 또는 제어 아이콘들)을 선택할 기회가 주어질 때 마다, 그때 그 아이콘들/키들의 설계는 단순하게 유지되고 연관된 터치 스크린 존들은 각각의 아이콘/키가 모호하지 않게 손가락으로 선택될 수 있는 크기로 확장된다. 실제로, 연관된 터치 스크린 존은 최소한 0.7 cm² 정도(order)일 것이고 전형적으로 직사각형 존일 것이다. 정상 내비게이션 모드에서, 그 기기는 맵을 디스플레이한다. 그 후에 화면 중심(또는 다른 구현에서는 화면의 임의의 부분) 근처에서 그 맵(즉, 터치 감지 디스플레이)을 한 번(또는 다른 구현에서는 두 번) 터치하는 것은, 다양한 내비게이션 기능들, 예컨대 대체 경로를 계산하고 그리고 다음 도로 부분을 회피하도록 그 경로를 재계산하거나(방해물 또는 심한 교통혼잡과 마주칠 때 유용함), 특정한, 리스트화된 도로들을 회피하도록 그 경로를 재계산하는 옵션에 대응되는 큰 아이콘들을 가진 내비게이션 메뉴(도 5 참조)를 직접적으로(즉, 아래로 다음 레벨) 혹은 간접적으로(즉 아래로 둘 이상의 레벨) 호출할 것이다.

그 기기의 실제 물리적 구조는 메모리 아키텍처(architecture)의 관점에서 볼 때 기존의 엠베디드 기기와는 근본적으로 다르다 (아래에서 시스템 아키텍쳐 섹션 참조). 그러나 고수준에서 그것은 유사하다: 메모리는 경로 계산 알고리즘들, 맵 데이터베이스 및 사용자 인터페이스 소프트웨어를 저장하고; 마이크로프로세서는 사용자 입력(예: 출발 및 목적지 주소들을 입력하기 위한 기기 터치 스크린 및 모든 다른 제어 입력들을 사용)을 해석하고 프로세싱하며 그 경로 계산 알고리즘들을 탑재하여 최적의 경로를 계산한다. '최적'이라는 것은 최단 시간 또는 최단 거리나 또는 어떤 다른 사용자관련 인자들과 같은 기준들을 가리킬 수도 있다.

더 구체적으로, 사용자는 가상 키보드를 사용하여 PDA 상에서 실행되는 Navigator 소프트웨어에 보통의 방식으로 그 사용자의 출발 위치와 요구되는 목적지를 입력한다. 그리고 나서 사용자는 진행 경로가 계산되는 방식을 선택한다: 다양한 모드들이 제공되는데, 예컨대 매우 빠르게 그 경로를 계산하지만, 그 경로가 가장 짧지 않을 수도 있는 '빠름' 모드, 모든 가능한 경로들을 조사하고 최단거리를 밝혀내지만, 계산하는 것 등을 위해 더 오래 걸리는 '완전' 모드 등이 제공된다. 다른 옵션들도 가능한데, 여기서 사용자는, 눈에 띄게 아름다운 경치들로서 마킹된 최고의 POI(point of interest)를 통과하거나 또는 어린이들에게 가능한 관심대상인 최고의 POI들을 통과하는, 경치가 아름다운 경로를 정의하거나 가장 적은 수의 교차점(junction)들을 이용하는 등의 경로를 정의할 수 있다.

도로들은 자체적으로, 선들 - 즉 벡터들(예: 이는 시작점, 종점, 도로 방향으로서, 여기서 완전한 도로는 수백 개의 이러한 부분들로 이루어지고, 그 각각은 시작점/종점 방향 파라미터들에 의해 고유하게 정의됨)로서, PDA 상에서 실행되는 Navigator의 일부인 (또는 그와 달리 그것에 의해 액세스되는) 맵 데이터베이스에서 그려진다. 그때 맵은 이러한 도로 벡터들과, 추가적으로 POI들, 도로 이름들, 공원 경계, 강 경계 등과 같은 다른 지리적 특징들의 집합으로, 이들 모두는 벡터로 정의된다. 모든 맵 특징들(예: 도로 벡터들, POI들 등)은 GPS 좌표 시스템에 대응되는 또는 그에 관련되는 좌표 시스템에서 정의되어, GPS 시스템을 통하여 결정된 기기의 위치를 맵에서 보이는 관련 도로 상에 위치시키는 것을 가능하게 한다.

도로 계산은 Navigator 소프트웨어의 부분인 복잡한 알고리즘들을 이용한다. 그 알고리즘들은 많은 잠재적인 상이한 경로들을 점수기록하도록(score) 적용된다. 그 후에 Navigator 소프트웨어는, 경치가 아름다운 경로, 역사 박물관들이 있지만 속도 카메라는 없는, 완전 모드 스캔(scan)과 같은 사용자 정의 기준들(또는 기기 디폴트(default)들)과 대비하여 그것들을 평가한다. 그러면 그 정의된 기준들을 가장 잘 충족시키는 경로는 PDA 내 프로세서에 의해 계산되고 그 후에 도로 이름들, 벡터 종점들에서 행해질 액션들(예: 100미터 후에 거리 x로 왼쪽으로 회전하라는 것과 같이, 그 경로의 각 도로를 따른 기결정된 거리들에 대응됨), 및 벡터들의 시퀀스로서 RAM 내 데이터베이스에 저장된다.

도 6a 및 도 6b는 내비게이션 기기의 실제 구현에 관한 원근도들이다. 그 내비게이션 기기는 디스플레이, 내부 GPS 수신기, 마이크로프로세서, 전원장치(power supply) 및 메모리 시스템들을 포함하는 유닛이다. 그 기기는 거치대(arm)에 위치하게 되고, 그 거치대는 큰 흡착기(suction cup)를 사용하여 차의 대시보드(dashboard)에 자체적으로 고정된다.

- 시스템 아키텍처

대용량 마스크 ROM(mask ROM) 또는 플래쉬(Flash) 기기로부터 적소에서 모든 OS 및 어플리케이션 코드를 실행하는 기존의 엠베디드 기기들과 대조적으로, 본 발명의 구현에서는 새로운 메모리 아키텍처를 사용한다. 도 7은 그 기기를 도식적으로 묘사하고 있다. 그 기기 - 전체로서 51로 표시됨 - 는 마이크로프로세서(56), 전원 소스(57), 디스플레이 및 관련 드라이버들(58)과 같은 기존의 항목들을 포함한다. 또한, 그것은 SD 카드 리더(53)를 포함한다; SD 카드(52)는 안쪽에 넣어져 있는 것으로 나타나 있다. 기기(51)는 내부 DRAM(54) 및 XIP 플래쉬(55)를 구비하고 있다.

따라서, 그 기기는 다음과 같은 메모리에 관한 3가지 상이한 형태들을 이용한다:

1. 소량의 내부 XIP(eXecute In Place) 플래쉬 ROM(55). 이것은 PC의 BIOS ROM과 유사하고 단지 독점적인 부트 로더(boot loader), (UID 및 제조 데이터를 위한) E² 에뮬레이션(emulation) 및 스플래쉬 스크린 비트 맵(splash screen bit map)들만을 포함할 것이다. 이것은 256 KB 크기일 것으로 추정되고 느린 8비트 폭의 SRAM 인터페이스에 접해 있을 것이다.

2. 메인 시스템 RAM(또는 DRAM) 메모리(54)로, 이것은 PC의 메인 메모리(RAM)와 유사하다. 이것은 OS 및 어플리케이션들을 위한 비디오 RAM 및 워크스페이스(workspace)를 제공할 뿐만 아니라 모든 메인 코드가 실행되는 곳일 것이다. 주의: 어떠한 영속적인 사용자 데이터도 (PC처럼) 메인 시스템 RAM에 저장되지 않을 것으로, 즉 어떠한 "램 드라이브"(Ram drive)도 없을 것이다. 이 RAM은 오직 32비트 100MHz 동기 고속 버스(high-speed bus)에만 연결될 것이다.

3. 비휘발성 저장소로, 이는 PC의 하드 디스크와 유사하다. 이것은 착탈식 NAND 플래쉬 기반 SD 카드들(52)로서 구현된다. 이들 기기들은 XIP를 지원하지 않는다. 모든 OS, 어플리케이션, 세팅(setting) 파일들 및 맵 데이터는 SD 카드들 상에 영구히 저장될 것이다.

부팅 시에 독점적 부트 로더(55)는 공급된 SD 카드(52)를 사용자가 삽입하도록 자극할 것이다(prompt). 이것이 행해진 때, 그 기기는 SD 카드(52)로부터 전용 시스템 파일을 RAM(54)에 복사할 것이다. 이 파일은 운영 시스템(Operating System) 및 내비게이션 어플리케이션을 포함할 것이다. 일단 이것이 완료되면 어플리케이션으로 제어가 넘어갈 것이다. 그러면 그 어플리케이션이 시작되어 비휘발성 데이터, 예로서 SD 카드(52)로부터의 맵들을 액세스한다.

그 기기가 그 후에 꺼지도록 스위치될 때, RAM(54) 콘텐츠는 유지보존되고 그래서 이 부팅 절차는 단지 처음 그 기기를 사용할 때만 일어난다.

- GO 제품 명세

- 서설

GO는 독립형의 완전히 통합된 개인 내비게이션 기기이다. 그것은 차량에 대한 어떠한 연결에 대해서도 독립적으로 작동할 것이다.

- 표적 시장

GO는 일반적인 개인 내비게이션 시장에 초점을 맞추도록 의도된 것이다. 특히 그것은 "얼리 어답터"(early adopter) 시장을 넘어 개인 내비게이션을 위한 시장을 확장하기 위해 계획된 것이다. 이러한 것으로서 그것은 완전한 독립형 솔루션이다; 그것은 인터넷 연결 또는 PC나 PDA에 대한 액세스를 필요로 하지 않는다. 완전성 및 사용의 용이성에 중점이 두어질 것이다.

비록 GO가 완전한 개인 내비게이션 솔루션임에도 불구하고, 그것은 주로 차량에서 사용되는 경우를 위해 의도된다. 주요 표적 시장은 비즈니스나 아니면 취 미(오락)를 위해 차량을 운전하는 자 누구든지이다.

성공적으로 이 시장을 다루기 위하여 GO는 다음의 최고 수준의 요구조건들을 만족시켜야 한다:

1. 수용가능한 기준 소매 가격(price point) - 제품 특징들 및 비용 간의 적절한 타협

2. 단순성 - GO의 설치 및 작동은 단순하고 직관적일 것, 모든 주요 기능들은 제품 매뉴얼에 의지하지 않으면서 PC 지식이 없는 평균적인 사용자에 의해 이루어져야 함.

3. 유연성(flexibility) - 모든 맵 데이터 및 운영 프로그램들은 메모리 카드들 내 플러그 상에서 공급될 것. 그 기기는 서로 다른 로컬들을 커버하도록 용이하게 확장될 수 있음.

4. 신뢰성(reliability) - 비록 차내 내비게이션 시스템들이 안전을 보장하는 결정적인 콤포넌트들로 고려되지 않음에도 불구하고 사용자들은 GO에 의존하게 될 것이다. 그것은 모든 관련 자동차 환경 표준들대로 만들어질 것이다. 게다가 그것은 짧은 GPS 커버리지 불능(outage)을 견딜 것이다.

- 채널들

● 소비자 전자제품 소매 아웃렛들

● 자동차 악세서리 아웃렛들

● 전문 자동차 액세서리 정비 공장들

- 제품 요약

GO는 차량내 개인 내비게이션 기기이다. 그것은, 말하자면, 범용 기능보다는 오히려 특정 기능을 위한 전자제품으로서 계획된다. 그것은 소비자 판매후의 자동차 시장을 위해 계획된다. 그것은 엔드 유저에 의해 사용하고 설치하기 단순할 것이지만, 전문적인 맞춤 킷(fitting kit)이 선택적으로 공급될 것이다.

주요한 특징들은 다음과 같다:

● 표준 상품의 포켓PC 2002 콤포넌트들을 기초로 함

● 가로형 포맷(landscape orientation)으로 설치된 표준 포켓PC 3.5인치 1/4VGA 반투과성(transflective) TFT LCD 디스플레이

● ROM없는(ROMless) 소프트-부트(soft-boot) 메모리 아키텍처

● 고도로 집적된 ARM9 200MHz CPU

● 어플리케이션 및 맵 데이터 저장을 위한 SD 카드 메모리 슬롯

● 통합된 GPS 수신기 및 안테나

● 단순한 추측 항법(dead reckoning)을 위한 통합된 2개 축 가속도계

● 유닛의 기부(base) 상에서 도킹 커넥터(docking connector)를 통해 만들어진 외부 GPS 안테나 연결들, 전원, 오디오 및 디버그(debug)

● 어떠한 GUI 층도 가지지 않은 엠베디드 리눅스 OS, 어플리케이션이 그 자신의 UI를 제공함

● 손가락으로 사용하기에 최적화된 매우 단순한 터치 스크린 UI

● 음성 지시를 위한 고품질의 통합 스피커

● 최소한 5시간의 연속 작동을 부여하는 내부의 충전가능한 리튬-이온 배터 리.

- 운영 시스템

GO는 엠베디드 리눅스의 커스터마이징된 버전을 사용할 것이다. 이것은 플래쉬 메모리에 있는 커스텀(custom) 부트-로더 프로그램에 의해 SD 카드로부터 로딩될 것이다.

- 하드 버튼( hard button )들

GO는 단지 하나의 하드 버튼인 전원 버튼을 가질 것이다. 그것은 GO를 켜거나 끄기 위해 한 번 눌러진다. UI는 모든 다른 동작들이 펜(pen) 기반 UI를 통해 용이하게 액세스가능하도록 설계될 것이다.

또한 숨겨진 하드 리셋 버튼도 있을 것이다.

- 아키텍처

GO 아키텍처는 모바일 컴퓨팅 기기들을 위해 설계된 고도로 집적된 단일 칩 프로세서에 기초한다. 이 기기는 산업 표준인 ARM920T 프로세서로부터 약 200 MIP의 성능을 전달한다. 그것은 또한 GPS 기저대역(base-band)을 제외하고 요구되는 모든 주변기기들을 포함한다. 이들 주변기기들은 DRAM 콘트롤러, 타이머/카운터들, UART들, SD 인터페이스 및 LCD 콘트롤러를 포함한다.

이 아키텍처의 주요 요소들은 다음과 같다:

● 200MHz로 실행되는 마이크로프로세서

● 저전력 자가 리프레쉬(refresh)를 갖는 32MB 또는 64MB의 고속 동기 DRAM (SDRAM); 32비트 폭 100MHz 버스 상에 2개 기기들로서 구성됨

● OS를 포함하는 모든 비휘발성 저장소를 위한 SD 카드 인터페이스 (RAM 드라이브는 아님)

● 256KB의 NOR 플래쉬에 저장된 원래상태의(native) (저장내용 없는(bare metal)) 부트 로더. 이 플래쉬 기기는 고유한 제품 ID 및 제조 데이터와 같은 보호 데이터를 저장하기 위해 쓰기 금지된 부트 섹터(boot sector)를 포함할 것이다.

● 도킹 커넥터에 연결된 디버그 UART(RS232 3V 레벨)

● PC 접속을 위한 USB 클라이언트

● 통합된 GPS 수신기

● 통합된 2개 축 가속도계

● PDA 및 모바일 전화 접속을 위한 선택적인 통합 블루투스 트랜시버

● I²S 코덱 및 증폭기를 통한 고품질 오디오

도 8은 GO 블록 다이어그램이다.

- 전력 관리

GO는 통합된 리튬-이온 2200 mAH 충전가능 배터리로부터 전력을 공급받을 것이다. 이 배터리는 충전될 수 있고, 그 기기는 외부에서 공급되는 +5V 전원으로부터 (그 배터리가 어떠한 충전도 포함하고 있지 않을지라도) 전력을 공급받는다. 이 외부 +5V 전원은 도킹 커넥터 또는 DC 잭 소켓을 통해 공급된다.

+5V 공급은 차량의 주 공급 레일(rail)로부터 또는 외부에서의 간선 어댑터(mains adapter)로부터 생성될 것이다. 그 기기는 단일 버튼에 의해 켜지고 꺼질 것이다. 그 기기가 꺼질 때 DRAM 콘텐츠는 자가-리프레쉬하는 RAM을 둠으로써 유지보존될 것이어서, 켜지도록 스위치될 때에는 GO는 그것이 꺼지도록 스위치되었던 데에서부터 재개할 것이다(resume). 또한 도킹 커넥터를 통해 이용가능한 웨이크업(wake-up) 신호가 있을 것이고, 이것은 차량 점화장치가 켜지도록 스위치될 때 GO를 자동으로 켜지게 스위치하는데 사용될 수 있다.

또한 작은 숨겨진 리셋 스위치도 있을 것이다.

- 시스템 메모리 아키텍처

대용량 마스크 ROM 또는 플래쉬 기기로부터 적소에서 모든 OS 및 어플리케이션 코드를 실행하는 기존의 엠베디드 기기들과 대조적으로, GO는 PC에 훨씬 더 가까운 새로운 메모리 아키텍처에 기반할 것이다.

이것은 다음과 같은 메모리에 관한 3가지 형태들로 이루어질 것이다:

4. 소량의 XIP(eXecute In Place) 플래쉬 ROM. 이것은 PC의 BIOS ROM과 유사하고 단지 독점적인 부트 로더, (UID 및 제조 데이터를 위한) E² 에뮬레이션 및 스플래쉬 스크린 비트 맵들만을 포함할 것이다. 이것은 256 KB 크기일 것으로 추정되고 느린 8비트 폭의 SRAM 인터페이스에 접해 있을 것이다.

5. 메인 시스템 메모리로, 이것은 PC의 메인 메모리(RAM)와 유사하다. 이것은 OS 및 어플리케이션들을 위한 비디오 RAM 및 워크스페이스를 제공할 뿐만 아니라 모든 메인 코드가 실행되는 곳일 것이다. 주의: 어떠한 영속적인 사용자 데이터도 (PC처럼) 메인 시스템 RAM에 저장되지 않을 것으로, 즉 어떠한 "램 드라이브"도 없을 것이다. 이 RAM은 오직 32비트 100MHz 동기 고속 버스에만 연결될 것이다. GO는 128 MB (32비트 폭) 및 64MB 32비트 폭과 32MB (16비트 폭)의 16비트 폭 256/512Mbit SDRAM의 허용 메모리 구성들을 위한 2개의 사이트(site)들을 포함할 것이다.

6. 비휘발성 저장소로, 이는 PC의 하드 디스크와 유사하다. 이것은 착탈식 NAND 플래쉬 기반 SD 카드들로서 구현된다. 이들 기기들은 XIP를 지원하지 않는다. 모든 OS, 어플리케이션, 세팅 파일들 및 맵 데이터는 SD 카드들 상에 영구히 저장될 것이다.

- 오디오

52 mm 직경의 스피커가 GO 내에 수용되어 양질의 음성 지시를 부여한다. 이것은 내부 증폭기 및 오디오 코덱에 의해 작동될 것이다. 오디오 라인 아웃(line out)도 또한 도킹 커넥터 상에 존재할 것이다.

- SD 메모리 슬롯

GO는 하나의 표준 SD 카드 소켓을 포함할 것이다. 이들은 시스템 소프트웨어를 로딩하기 위해 그리고 맵 데이터를 액세스하기 위해 사용된다.

- 디스플레이

GO는 반투과성 3.5인치 TFT 백라이트(backlit) 디스플레이를 이용할 것이다. 그것은 포켓PC PDA에 의해 사용되는 '표준' 1/4VGA 디스플레이일 것이다. 그것은 또한 터치 패널(touch panel) 및 밝은 CCFL 백라이트를 포함할 것이다.

- 전력 공급

- 전력 공급 - AC 어댑터 소켓

4.75V 내지 5.25V (5.00V +/- 5%) @ 2A

- 전력 공급 - 도킹 커넥터

4.75V 내지 5.25V (5.00V +/- 5%) @ 2A

- 변형예들

GO에 관한 다음 변형예들을 결집하고 테스트하는 것이 가능하여야 할 것이다:

- 표준 (블루투스 미탑재, 32 Mbyte RAM )

표준 변형예에서 블루투스 기능이 탑재되지 않아서, 32 Mbyte RAM이 적합하다.

- 블루투스 옵션 (미래의 변형예 )

비록 BOM 비용을 최소화하기 위하여 표준 변형예에서 블루투스가 탑재되지 않지만 이 제품 설계는 블루투스를 포함하여야 할 것이다. 그 설계는 블루투스 기능이 작동하고 있을 때 모든 다른 기능들(GPS RF 성능 포함)이 저하됨이 없이 작동함을 보증하여야 할 것이다.

- 64 Mbyte RAM 옵션 (미래의 변형예 )

이 제품 설계는 32Mbyte 대신에 64Mbyte RAM에 적합시키는 것이 가능함을 보증하여야 할 것이다.

- 하위부품들(subassemblies)

GO는 도 9에서 보이는 바와 같이 다음의 전기적 하위부품들로 이루어져 있 다.

- RF 케이블

RF 케이블은 외부 GPS 안테나(이는 RF 도킹 커넥터를 거쳐 GO에 연결됨)로부터의 RF 신호를 GPS 모듈이 위치해 있는 RF PCB로 피드한다.

- 외부 커넥터들

- 도킹 커넥터들

2개의 도킹 커넥터들은 외부의 도킹 스테이션(Docking Station)들에 대한 인터페이스를 제공한다.

- 도킹 커넥터 #1의 핀아웃( pinout )

Pin	Signal	Dir	Type	설명
1	GND	-	-	신호 및 전력 GND
2	GND	-	-	신호 및 전력 GND
3	DOCKSNS1	I/P	PU	도킹 스테이션 의미(Sense) [0,1] - 이들 신호들은 장치 내 풀업(pull-up) 저항기들에 연결된다. 도킹 스테이션은 도킹 스테이션의 존재 및 유형을 나타내기 위해 이들 신호들 중 어느 하나 또는 양자 모두를 GND로 이끈다(pull).
4	DOCKSNS0	I/P	PU
5	AUDIOL	O/P		차 오디오 시스템에 연결할 오디오 라인 출력들(왼쪽(Left) 및 오른쪽(Right))
6	AUDIOR	O/P		차 오디오 시스템에 연결할 오디오 라인 출력들(왼쪽(Left) 및 오른쪽(Right))
7	MUTE	O/P	O/D	장치는 그 장치가 음성 명령을 제기하고 있는 동안 차 오디오 시스템이 그 차 오디오 시스템 자체를 뮤팅(muting)하도록 신호하기 위해 이 라인을 GND로 이끈다.
8	IGNITION	I/P	PD	점화 의미
9	DOCKPWR	I/P	PWR	장치에 전력을 공급하고 동시에 배터리를 충전하기 위해 도킹 스테이션으로부터의 +5V 전력
10	DOCKPWR	I/P	PWR	장치에 전력을 공급하고 동시에 배터리를 충전하기 위해 도킹 스테이션으로부터의 +5V 전력

여기서 PWR은 전력 연결(Power connection)을, PU는 그 장치 내 풀업 저항기(Pull-Up resistor), O/D는 개방-드레인 출력(Open-Drain output), 그리고 PD는 그 장치 내 풀다운 저항기(Pull-Down resistor)를 의미한다.

- 도킹 커넥터 #2의 핀아웃

Pin	Signal	Dir	Type	설명
1	TXD	O/P	UART	3V 로직 레벨 UART 신호들
2	RXD	I/P	UART
3	RTS	O/P	UART
4	CTS	I/P	UART
5	GND	-	PWR
6	nTRST	I/P	JTAG	테스트 및 설정(configuration)을 위한 CPU JTAG 신호들
7	TMS	I/P	JTAG
8	TCK	I/P	JTAG
9	TDI	I/P	JTAG
10	TDO	O/P	JTAG

- RF 도킹 커넥터

RF 도킹 커넥터는 도킹 스테이션을 경유하여 외부의 활동 GPS 안테나를 연결하는 것을 가능하게 해 준다.

- AC 어댑터 소켓

AC 어댑터 소켓은 전력이 저비용의 AC 어댑터 또는 CLA(Cigarette Lighter Adapter)로부터 공급되는 것을 가능하게 해 준다.

- USB 커넥터

USB 커넥터는 표준의 미니 USB 케이블로 PC에 연결하는 것을 가능하게 해 준다.

- SD 카드 소켓

고진동 적용에 적합한 하드 로킹(hard locking) SD 카드 소켓은 SDIO, SD 메모리 및 MMC 카드들을 지원한다.

(비록 GO가 SDIO에 대한 하드웨어 지원을 제공하지만, 소프트웨어 지원은 제품 도입 시에 이용가능하지 않을 것이다)

- 프로세서

프로세서는 약 200Mhz에서 작동하는 ARM920T 기반 SOC(System on chip)이다.

- RAM

GO는 RAM에 관하여 다음의 명세에 적합될 것이다:

유형	저전력 리프레쉬를 가지는 SDRAM ("모바일" SDRAM)
총 메모리	32 Mbyte (표준) 또는 64 Mbyte (미래 옵션)
버스 폭(Bus width)	32비트
최소 속도	100Mhz
최대 자가 리프레쉬 전류	기기당 500μA
설정	2×16비트 폭 CSP 사이트들

- 플래쉬 메모리

GO는 다음을 포함할 최소 256kbyte의 16비트 폭 플래쉬 메모리로 적합될 것이다:

● SD 카드로부터 O/S의 로딩을 할 수 있게 하는 부트 로더 코드

● 공장에서 세팅된 읽기전용으로 보호되는 제조 파라미터들(예: 제조일) 및 고유 ID (E2PROM 에뮬레이션)

● 사용자 특정 세팅들(user specific settings) (E2PROM 에뮬레이션)

다음의 기기들이 가격 및 가용성에 따라 사용될 수 있다:

- GPS 내부 안테나

GPS 내부 안테나는 RF PCB에 직접 달린다.

- GPS 외부 (활동) 안테나 스위칭

외부 안테나가 RF 도킹 커넥터를 통해 연결될 때, GPS 안테나 소스는 자동적으로 외부 안테나로 스위칭된다.

- 가속도계

고체 상태 가속도계는 속도 및 방향 변경에 관한 정보를 제공하기 위해 프로세서에 직접 연결된다.

- 보조 기능들

- 점화 동기화

점화 웨이크업

도킹 스테이션 IGNITION 신호 상의 상승 에지(rising edge)는 장치를 웨이크업할 것이다. IGNITION 신호는 12V 또는 24V 차량 배터리에 연결될 수도 있다.

점화 상태 모니터링

도킹 스테이션 IGNITION 신호의 상태가 탐지되고 그리고 그 점화(ignition) 신호가 로우(low)가 될 때 소프트웨어가 장치를 끄게 할 수 있게 하기 위해 GPIO 핀으로 피드된다.

- 표준 주변기기들

다음의 주변기기들이 GO에 관하여 표준으로서 포함될 것이다.

- 단순한 도킹 슈(shoe). GO를 설치하고 DC 잭을 통해 충전하는 것을 가능하게 해 줌. 어떠한 다른 연결도 그 단순 잭에 포함되지 않음.

- DC 잭 소켓 또는 단순 도킹 슈를 통해 GO에 연결하고 있는 담배 라이터 전원 케이블

- PC 접속을 위한 미니 USB 케이블

- DC 잭 소켓으로의 연결을 위한 보편적인 간선 어댑터(universal mains adapter).

- 선택적 주변기기들

다음의 선택적인 주변기기들이 GO의 응용프로그램 시작 시간에 또는 그 후에 이용가능할 것이다.

- 활동적인 안테나 킷. 이는 적합한 케이블 및 GPS RF 커넥터를 가진 도킹 슈 및 GPS 활동 안테나를 포함. 외부 안테나가 요구될 때 자가 설치를 위한 것.

- 전문적인 차량 도킹 킷. 단지 전문적인 설치에 적합하기 위한 것임. 차량 인터페이스 박스(interface box)를 거쳐 차량 전원(supply), 오디오 시스템 및 활동 안테나에 대한 직접 연결을 허용.

- 부록 2

Map Share 고수준 요구조건들(0.40)

- 서론

TomTom은 소비자들에게 이용가능한 가장 정확한 맵 데이터를 제공하려고 노력한다. 현재, 맵 업데이트들이 TomTom 맵 공급자들에 의해 이루어지고 있고, TomTom은 Tele Atlas로 보고 툴을 거쳐 어떤 맵들에서의 오류들을 피드백할 수 있다. 이 상황은 맵 오류가 정정되기 전에 몇몇 맵 개정들을 행할 수도 있고, TomTom 오류 보고들의 결과로서 이루어지는 모든 정정들도 또한 경쟁자들과 공유되기 때문에 이상적인 것과는 거리가 멀다. TomTom이 스케줄대로 맵 업데이트들을 제공하기 위해서, 새로운 맵 오류 보고 및 정정 시스템이 요구된다. 이들 개선점들은 Map Share 프로젝트를 통해 전해질 것이다.

1.1 범위

여기서는 Map Share 프로젝트의 고수준 요구조건들을 설명하고 있다.

2 고수준 요구조건들

이 섹션은 Map Share의 고수준 요구조건들을 설명하고 있다.

2.1 사용자 요구조건들

이 섹션은 Map Share를 위한 사용자 요구조건들을 설명하고 있다.

2.1.1 맵 정정들

어떤 맵 오류들은 사용자에 의해 즉각적으로 정정될 수 있다. 이 섹션은 맵 정정들에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.1.1 기기상 맵 정정들

사용자는 그들의 NavCore 기기 상에서 맵 정정을 행할 수 있어야 할 것이다.

2.1.1.2 TomTom Home 맵 정정들

사용자는 TomTom Home 어플리케이션의 Navigator 제어 안에서 맵 정정을 행할 수 있어야 할 것이다.

2.1.2 맵 정정 유형들

이 섹션은 행해질 수 있는 맵 정정의 유형들에 관련된 사용자 요구조건들을 기술하고 있다.

2.1.2.1 안전 카메라 추가

사용자는 맵 상에 안전 카메라들의 위치들을 추가할 수 있어야 할 것이다.

주의: 이러한 식으로 안전 카메라들을 보고하는 것은 이미 가능한 것이지만, 그 구현은 보고 절차를 단순화하기 위해 조정되어야 하고, 그것을 다른 맵 정정들과 일관성 있게 만들어주고 사용자들이 보고했던 안전 카메라들을 즉각적으로 사용자들로 하여금 볼 수 있게 해 준다.

2.1.2.2 도로를 블록

사용자는 맵 상의 도로들을 블록할 수 있어야 할 것이다.

2.1.2.3 도로를 언블록

사용자는 맵 상의 도로들을 언블록할 수 있어야 할 것이다.

2.1.2.4 교통 방향 수정

사용자는 맵 상에 도로들의 교통 방향 속성들을 수정할 수 있어야 할 것이다.

구체적으로 사용자는 다음을 할 수 있어야 할 것이다:

● 양방향 도로를 단방향 도로로 변경 (어느 한쪽 방향으로)

● 단방향 도로를 양방향 도로로 변경

● 단방향 도로의 방향을 그와 다른 방향으로 변경.

2.1.2.5 도로 추가

사용자는 맵 상에 도로(하나 이상의 노드들로 이루어짐)를 추가할 수 있어야 할 것이다.

2.1.2.6 도로 연결

사용자는 맵 상에 2개의 점들을 연결하여 새로운 링크를 새로운 도로로서 정 의할 수 있어야 할 것이다.

2.1.2.7 거리 이름 추가

사용자는 거리 이름들을 맵 상의 이름없는 거리들에 추가할 수 있어야 할 것이다.

2.1.2.8 거리 이름 수정

사용자는 맵 상의 도로들의 이름들을 수정할 수 있어야 할 것이다.

2.1.2.9 속도 제한 수정

사용자는 맵 상에서 도로들의 최대 속도를 수정할 수 있어야 할 것이다.

2.1.3 기기상 정정들의 이용가능성

일단 맵 정정들이 NavCore 기기 상에 존재한다면, 그것들은 사용자에게 이용가능하게 되어야 한다. 이 섹션은 기기상 정정들의 이용가능성에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.3.1 사적 정정들의 이용가능성

사용자는 사적 정정들이 기록되자마자 그 사적 정정들을 사용할 수 있어야 할 것이다.

2.1.3.2 공적 정정들의 이용가능성

사용자는 공적 정정들이 기기로 다운로드되자마자 그 공적 정정들을 사용할 수 있어야 할 것이다.

2.1.4 맵 정정들의 사용

어떤 맵 정정들이 다른 TomTom 소유자들에 의해 이루어졌을 수도 있기 때문 에, 사용자는 경로들을 계산시 어느 정정들을 사용할 것인지를 선택할 수 있어야 한다. 이 섹션은 사용자 기기 상의 맵 정정들의 사용에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.4.1 안전 카메라 경고

사용자는 사적 및/또는 공적 피보고 안전 카메라들에 대한 경고들을 수시할지 여부를 선택할 수 있어야 할 것이다.

2.1.4.2 사적 맵 정정 사용

사용자는 그들이 정정을 포함한 경로를 계획할 때에는 어느 때라도 그들의 사적 맵 정정들을 사용하거나 무시할 수 있어야 할 것이다.

2.1.4.3 공적 맵 정정 사용

사용자는 그들이 정정을 포함한 경로를 계획할 때에는 어느 때라도 그들의 공적 맵 정정들을 사용하거나 무시할 수 있어야 할 것이다.

2.1.4.4 자동적인 맵 정정 사용

사용자는 하나 이상의 카테고리들로부터의 사적 및/또는 공적 정정들이 자동적으로 경로 계산 내에 포함되도록 그들 기기를 설정할 수 있어야 할 것이다. 사용자는 그들이 정정들을 사용하고 있음을 알고 있어야 할 것이다.

2.1.4.5 경로 재계산

사용자는 맵 정정들을 포함하거나 또는 배제하도록 경로들을 재계산할 수 있어야 할 것이다.

2.1.4.6 맵 정정 제거

사용자는 그들 기기로부터 맵 정정을 제거할 수 있어야 할 것이다.

2.1.5 맵 오류 보고

어떤 맵 오류들은 스케일(scale)에 있어서 너무 복잡하거나 또는 커서 기기 그 자체 상에서 정정을 행할 수 없다. 우리(또는 우리의 맵 공급자들)가 정정 활동을 할 수 있기 위해, 이들 오류들은 TomTom에 보고될 필요가 있다. 이 섹션은 맵 오류 보고에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.5.1 기기상 맵 오류 보고

사용자는 그들 기기 상에서 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

주의: 사용자는 운전하는 동안 맵 오류 보고들을 생성할 수 없어야 할 것이다.

주의: 기기 상에서 오류 보고들을 생성시 기정의된 오류 유형들의 리스트를 사용자들에게 제공하는 것이 수용될 것이다.

2.1.5.2 TomTom Home 맵 오류 보고

사용자는 TomTom Home의 Navigator 제어 내에서 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

주의: 사용자는 맵 오류 보고를 생성하기 위해 TomTom 소비자로서 등록하여야 하는 것은 아니어야 할 것이다.

2.1.5.3 TomTom Home 에 기기상 오류 보고들의 가져오기( importing )

사용자는 그들 기기 상에서 포착된 맵 오류 보고들을 TomTom Home 어플리케 이션으로 가져오기할 수 있어야 할 것이다. 사용자는 이들 보고들을 편집하여 그 후에 그것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

2.1.5.4 맵 오류 보고 피드백

사용자는 그들의 맵 오류 보고들에 관하여 피드백이 주어져야 할 것이다.

2.1.6 자동적인 맵 오류 식별

어떤 환경들에서는 TomTom 기기가 그 제품의 사용에 기초하여, 사용자에게 정정들을 제안하는 것이 가능하다. 이 섹션은 맵 오류들의 자동적인 식별에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.6.1 자동적인 도로 블록 제안

사용자는 여러 차례 경로 계획들 내 그들이 피하기를 선택하는 도로들을 블록하도록 자극되어야 할 것이다.

2.1.6.2 자동적인 도로 생성 제안

사용자는 여러 차례 그들이 도로로서 마킹되지 않은 맵 구역을 지나며 운전한다면 그 맵 상에서 도로를 추가하도록 자극되어야 할 것이다.

2.1.6.3 자동적인 도로 이름 제안

사용자는 여러 차례 그들이 이러한 도로에 대한 경로들을 계획한다면 그 맵 상에서 이름없는 도로들에 이름을 덧붙이도록 자극되어야 할 것이다.

2.1.6.4 자동적인 속도 제한 수정 제안

사용자는 여러 차례 그들이 맵 데이터에서 지정된 것과 상당히 다른 속도로 도로를 따라 운전한다면 그 도로의 속도 제한을 수정하도록 자극되어야 할 것이다.

2.1.7 맵 정정 공유

Map Share의 사용자들은 다른 TomTom 소유자들과 그들의 정정들을 공유하기를 희망한다. 이 섹션은 다른 TomTom 소유자들과 맵 정정들을 공유할 수 있는 사용자 능력에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.7.1 사적 맵 정정들

사용자는 그들의 개인적인 사용만을 위한 정정들을 생성할 수 있어야 할 것이다. 이들 정정들은 TomTom PLUS 서버에 송신되어서는 안될 것이다.

2.1.7.2 공적 맵 정정들

사용자는 다른 TomTom 소유자들과 공유되는 정정들을 생성할 수 있어야 할 것이다. 이들 정정들은 TomTom PLUS 서버에 업로드되어 다른 Map Share 사용자들에게 이용가능해져야 할 것이다.

2.1.7.3 공적 맵 정정 커뮤니티 분류

사용자는 적용가능한 사용자 커뮤니티에 따라 그들의 공적 맵 정정들을 분류할 수 있어야 할 것이다. 다음의 커뮤니티 카테고리들이 이용가능하게 되어야 할 것이다:

● 모든 사용자들

● 모든 자동차 운전자들

● 대형 수송차 운전자들

● 오토바이 운전자들

● 제한 속도 차량 운전자들

● 보행자들

● 자전거들

2.1.7.4 신뢰받는 사용자 지위

사용자는, 그들이 업로드한 맵 정정들의 수와 질에 기초하여, "신뢰받는 사용자" 지위를 획득할 수 있어야 할 것이다.

2.1.7.5 맵 정정 정보

사용자는 그들이 사용하고 있는 맵 데이터의 더 새로운 버전에서 정정되었던 맵 정정을 보고하려고 시도하는지를 알아야 할 것이다. 사용자는 또한 그들이 업데이트된 맵을 어떻게 구입할 수 있을지를 알아야 할 것이다.

2.1.8 맵 정정 검색

공적 맵 정정들을 사용하기 위해 사용자는 TomTom PLUS 서버로부터 그것들을 검색하여야 한다. 이 섹션은 맵 정정 검색에 관련된 사용자 요구조건들을 설명하고 있다.

2.1.8.1 공적 맵 정정 검색

사용자는 TomTom PLUS 서버로부터 그들의 기기로, 그리고 TomTom Home 어플리케이션으로 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

2.1.8.2 공적 맵 정정 커뮤니티 카테고리 검색

사용자는 하나 이상의 커뮤니티 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 공적 정정 커뮤니티 카테고리들은 섹션 2.1.7.3에 정의되어 있다.

2.1.8.3 공적 맵 정정 소스 카테고리 검색

사용자는 하나 이상의 커뮤니티 소스 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 공적 정정 소스 카테고리들은 섹션 2.2.1.5에 정의되어 있다.

2.1.8.4 공적 맵 정정 공급자 카테고리 검색

사용자는 하나 이상의 맵 공급자 소스 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다. 공급자 카테고리는 각각의 TomTom 맵 공급자에 대해 제공되어야 할 것이다.

2.1.8.5 공적 맵 정정 위치 카테고리 검색

사용자는 하나 이상의 위치 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 다음의 카테고리들이 이용가능할 것이다:

● 모든 맵들

● 기기 상의 모든 맵들

● 기기 상에 현재 로딩된 맵

2.2 기술적 제약( Technical Constraint )들

Map Share 내 어떤 특징들은 사용자 요구조건들을 다루고 TomTom의 이익을 보호하기 위해 특정 방법으로 구현되어야 한다. 이 섹션은 Map Share의 V1 범위에 두어진 모든 알려진 기술적 제약들을 설명하고 있다.

2.2.1 공적 맵 정정 관리

사용자들로 하여금 공적 맵 정정들에 관련된 결정들을 알게 해 주기 위해, Map Share는 이들 정정들을 관리하여야 한다. 이 섹션은 맵 정정 분류에 관련된 제약들을 설명하고 있다.

2.2.1.1 맵 정정 모음

TomTom은 TomTom PLUS 서버에 송신된 모든 공적 맵 정정들을 모아야 할 것이다.

2.2.1.2 맵 정정 분석

공적 맵 정정들은 그들의 소스, 가용성(applicability) 및 신뢰성을 평가하기 위해 분석되어야 할 것이다.

2.2.1.3 맵 정정 배포

TomTom은 요청 시에 Map Share 사용자들에게 모든 공적 맵 정정들을 배포하여야 할 것이다.

2.2.1.4 맵 정정 제거

TomTom은 사용자들에게 공급되는 각각의 맵에 대한 각 맵 정정의 가용성을 평가하여야 할 것이다. 만약 맵 정정이 주어진 맵에 대하여 적용가능하지 않은 것으로 확인되면 그때는 그것은 모아진 맵 정정들로부터 제거되어 이 맵의 사용자들에게 배포되지 않아야 할 것이다.

2.2.1.5 맵 정정 소스 카테고리들

TomTom PLUS 서버 상에 보유된 맵 정정들은, 정정의 소스에 관한 상대적 신뢰성에 관해 사용자가 알 수 있도록, 소스에 따라 분류되어야 할 것이다.

2.2.1.5.1 TomTom 승인( Endorsement )

TomTom은 특정 맵 정정들을 승인할 수 있어야 할 것이고 이것들은 특정 카테고리에서 사용자에게 표현되어야 할 것이다.

2.2.1.5.2 단순 사용자 보고들

단일 사용자에 의해 보고되었던 맵 정정들은 특정 카테고리에서 다른 사용자들에게 표현되어야 할 것이다.

2.2.1.5.3 다수 사용자 보고들

한 명 이상의 사용자에 의해 보고되었던 맵 정정들은 특정 카테고리들에서 다른 사용자들에게 표현되어야 할 것이다. 구체적으로, 다음의 카테고리들이 표현되어야 할 것이다:

● 2-5명 사용자 보고들

● 5명 이상의 사용자 보고들.

2.2.1.5.4 신뢰받는 사용자 보고들

신뢰받는 사용자들에 의해 보고되었던 맵 정정들은 특정 카테고리에서 다른 사용자들에게 표현되어야 할 것이다.

2.2.1.5.5 커뮤니티 승인

Map Share 사용자들은 다른 TomTom 소유자들에 의해 만들어진 맵 정정들을 승인할 수 있어야 할 것이고 이들 승인들의 증거(징표)가 사용자에게 표현되어야 할 것이다.

2.2.2 데이터 포맷

Map Share로부터 경쟁적인 이득을 얻기(그리고 유지하기) 위해서, 맵 정정 데이터는 구조화된, 재사용가능한 그리고 안전한 방식으로 보유되는 것이 필수적이다. 이 섹션은 보안에 관련된 제약들을 설명하고 있다.

2.2.2.1 고유한 식별

각 맵 정정은 고유하게 식별되어야 할 것이다.

2.2.2.2 타임 스탬프( Time Stamp )

기기 상에서 포착된 각 맵 정정은 그것이 입력되었던 그리고/또는 보고되었던 시간으로 타임 스탬프되어야 할 것이다.

2.2.2.3 모듈성( Modularity )

각 맵 정정은 그것이 모든 다른 맵 정정들과 무관하게 맵에 적용될 수 있게 해주는 형태로 저장되어야 할 것이다 (즉 NavCore는 정정이 맵에 적용되고 사용자에게 표현되어야 할지 여부를 정정별로 결정할 수 있어야 할 것이다).

2.2.2.4 비영속적 수정

맵 정정들은 사용자의 맵 데이터에 대해 영속적인 수정을 하지 않아야 할 것이다.

2.2.2.5 데이터 압축

맵 정정들은 무선 네트워크들을 거쳐 빠르고 저렴한 배포를 가능하게 해 주도록 고도로 압축가능하여야 할 것이다.

2.2.2.6 데이터 암호화

맵 정정들은 데이터 포맷이 리버스 엔지니어링되는 것이 가능하지 않도록 고 도로 암호화되어야 할 것이다.

2.2.2.7 데이터 보전( Data Integrity )

맵 정정들은 그것들이 맵 업그레이드 프로세스를 거치면서 계속 유지되는 방식으로 저장되어야 할 것이다.

2.2.2.8 미래 맵 버전 호환성

맵 정정들은, 더 오래된 맵 버전들 상에서 이루어진 정정들이 최근의 버전에 적용될 수 있도록, 미래 맵 버전들과 호환성이 있어야 할 것이다.

2.2.2.9 과거 맵 버전 비호환성

맵 정정들은 과거 맵 버전들과 호환성이 잇지 않아야 할 것이다. 과거 맵 버전에 관해 현재 맵 버전 상에서 이루어진 맵 정정을 적용시키는 것이 가능하지 않아야 할 것이다.

2.2.2.10 맵 공급자 독립성

맵 정정들은, 맵 정정들이 서로 다른 공급자들로부터의 맵들에 적용될 수 있도록, 맵 공급자에 관해 독립적이어야 할 것이다.

2.2.2.11 Tele Atlas API 호환성

맵 정정들은, TomTom이 그렇게 하기를 희망하면 Tele Atlas에게 정확히 포맷화된 보고들을 송신할 수 있도록, Tele Atlas 맵 보고 API와 호환성 있는 포맷으로 저장되어야 할 것이다.

2.2.3 기기상 맵 정정 핸들링

맵 정정이 사용자의 기기 상에서 정확하게 핸들링됨을 보증하기 위해, 일정 한 규칙들이 적용되어야 한다. 이 섹션은 기기상 맵 정정 핸들링에 관련된 제약들을 설명하고 있다.

2.2.3.1 자동적인 맵 정정 생략

과거 맵 버전들 상에서 생성된 맵 정정들은 그것들이 사용자 기기 상에서 현재 로딩된 맵에 적용가능한지 여부를 알기 위해 조사되어야 할 것이다. 적용가능하지 않은 맵 정정들은 경로 계산 내에서 사용되어서는 안될 것이다.

2.2.4 맵 오류 보고 관리

더 효과적인 방식으로 맵 오류 보고들을 관리하기 위해, TomTom은 오류 보고들을 모으고 우선순위화하는 방법을 구현하여야 한다. 이 섹션은 맵 오류 보고 관리에 관련된 제약들을 설명하고 있다.

2.2.4.1 맵 오류 보고 포맷

모든 맵 오류 보고들은 Tele Atlas 맵 오류 보고 API와 호환성 있는 포맷으로 생성되어야 할 것이다.

2.2.4.2 맵 오류 보고 모음

TomTom은 사용자 기기들, TomTom Home 및 TomTom 웹사이트로부터 모든 맵 오류 보고들을 모아야 할 것이다.

2.2.4.3 맵 오류 보고 우선순위화

TomTom은 모든 맵 오류 보고들을 평가하고, 가장 심각한 오류들이 명백하게 하이라이트(highlight)되도록, 이것들에 대해 우선순위를 할당하여야 할 것이다. TomTom 맵 공급자들에게 오류 보고들을 제출시 이들 우선순위들은 그 TomTom 맵 공 급자들에 대해 송수신되어야 할 것이다.

2.2.4.4 Tele Atlas API 호환성

맵 오류 보고들은, TomTom이 그렇게 하기를 희망하면 Tele Atlas에게 정확하게 포맷화된 보고들을 송신할 수 있도록, Tele Atlas 맵 보고 API와 호환성 있는 포맷으로 저장되어야 할 것이다.

3. 생략

이 섹션은 Map Share의 V1 범위(scope)로부터 생략되었던 고수준 요구조건들을 설명하고 있다.

3.1 사용자 요구조건들

이 섹션은 Map Share에 대한 생략된 사용자 요구조건들을 설명하고 있다.

3.3.1 맵 정정 유형들

이 섹션은 Map Share의 V1 범위로부터 생략되었던 맵 정정 유형들을 설명하고 있다.

3.1.1.1 도시/장소 이름 수정

사용자는 맵 상에 도시들(및 다른 장소들)의 이름들을 수정할 수 있어야 할 것이다.

3.1.1.2 운송 유형에 대한 도로를 블록

사용자는 하나 이상의 운송 유형들에 대하여 도로의 통로(access)를 블록할 수 있어야 할 것이다. 구체적으로 사용자는 다음의 운송 유형들에 대하여 통로를 블록할 수 있어야 할 것이다:

● 모든 자동차들

● 보행자들

● 대형 수송차들

● 자전거들.

3.1.1.3 운송 유형에 대한 도로를 언블록

사용자는 하나 이상의 운송 유형들에 대하여 도로의 통로를 언블록할 수 있어야 할 것이다. 구체적으로 사용자는 다음의 전송 유형들에 대하여 통로를 언블록할 수 있어야 할 것이다:

● 모든 자동차들

● 보행자들

● 대형 수송차들

● 자전거들.

3.1.1.4 도로 클래스 수정

사용자는 맵 상에 도로들의 "클래스"를 수정할 수 있어야 할 것이다.

주의: 도로 클래스들은 도로들의 속성들을 정의하기 위해 사용되고 경로 계산 내에서 사용된다.

3.1.1.5 회전 제한 추가

사용자는 맵 상의 도로들에 회전 제한들을 추가할 수 있어야 할 것이다.

3.1.1.6 회전 제한 제거

사용자는 맵 상의 도로들에 적용되는 회전 제한들을 제거할 수 있어야 할 것 이다.

3.1.1.7 가옥 번호( House Number ) 추가

사용자는 맵 상의 도로들에 가옥 번호들(단일 번호 또는 범위 중 어느 한 쪽)을 추가할 수 있어야 할 것이다.

3.1.1.8 가옥 번호 수정

사용자는 맵 상의 도로들에 적용된 가옥 번호들(단일 번호 또는 범위 중 어느 한 쪽)의 위치를 수정할 수 있어야 할 것이다.

3.1.1.9 평균 속도 수정

사용자는 맵 상의 도로들의 평균 속도를 수정할 수 있어야 할 것이다.

3.1.1.10 도로에 톨( Toll ) 추가

사용자는 톨 도로로서 맵 상의 도로를 마킹할 수 있어야 할 것이다.

3.1.1.11 도로에서 톨 제거

사용자는 맵 상의 도로들로부터 톨의 존재를 제거할 수 있어야 할 것이다.

3.1.1.12 교통표지 추가

사용자는 맵 상의 도로들에 교통표지 정보를 추가할 수 있어야 할 것이다.

3.1.1.13 교통표지 수정

사용자는 맵 상의 도로들과 연관된 교통표지 정보의 속성들을 수정할 수 있어야 할 것이다.

3.1.1.14 교통표지 제거

사용자는 맵 상의 도로들과 연관된 교통표지 정보를 제거할 수 있어야 할 것 이다.

3.1.1.15 POI 위치 수정

사용자는 맵 상에 POI의 위치를 수정할 수 있어야 할 것이다.

3.1.1.16 POI 이름 수정

사용자는 맵 상에 POI의 이름들을 수정할 수 있어야 할 것이다.

3.1.1.17 POI 카테고리 수정

사용자는 맵 상에 POI의 카테고리를 수정할 수 있어야 할 것이다.

3.1.1.18 POI 제거

사용자는 맵으로부터 POI를 제거할 수 있어야 할 것이다.

3.1.1.19 고속도로 출구 번호 수정

사용자는 맵 상의 고속도로들의 출구 번호들을 수정할 수 있어야 할 것이다.

3.1.1.20 우편번호 수정

사용자는 맵 상의 도로와 연관된 우편번호를 수정할 수 있어야 할 것이다.

3.1.1.21 도로 높이 제한 추가

사용자는 맵 상의 도로들에 도로 높이 제한들을 추가할 수 있어야 할 것이다.

3.1.1.22 도로폭 제한 추가

사용자는 맵 상의 도로들에 도로폭 제한들을 추가할 수 있어야 할 것이다.

3.1.1.23 도로 중량 제한 추가

사용자는 맵 상의 도로들에 도로 중량 제한들을 추가할 수 있어야 할 것이 다.

3.1.2 맵 오류 보고

어떤 맵 오류들은 스케일에 있어 너무 복잡하거나 너무 커서 기기 그 자체 상에서 정정을 수행할 수 없다. 우리 (또는 우리의 맵 공급자들)가 정정 활동을 취할 수 있기 위해, 이들 오류들은 TomTom에 보고될 필요가 있다. 이 섹션은 맵 오류 보고에 관련된 사용자 요구조건들을 설명하고 있다.

3.1.2.1 TomTom 웹사이트 맵 오류 보고

사용자는 TomTom Support Website(TomTom 지원 웹사이트) 내에 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

● 사용자들은 맵 오류 보고를 생성하기 위해 TomTom 소비자로서 등록할 필요가 있어야 하는 것은 아니다.

● 그래픽 사용자 인터페이스는 맵 오류 위치들을 더 용이하게 선택할 수 있게 해 주도록 이용가능하게 되어야 할 것이다.

● 그들 보고의 상태에 관하여 피드백이 사용자에게 주어져야 할 것이다.

3.2 기술적 제약들

Map Share 내 어떤 특징들은 사용자 요구조건들을 다루고 TomTom의 이익을 보호하기 위해 특정 방식으로 구현되어야 한다. 이 섹션은 Map Share의 V1 범위로부터 생략되었던 모든 알려진 기술적 제약들을 설명하고 있다.

3.2.1 맵 오류 보고

이 섹션은 Map Share의 V1 범위로부터 생략되었던 맵 오류 보고에 관련된 모 든 알려진 기술적 제약들을 설명하고 있다.

3.2.1.1 Tele Atlas 로의 맵 오류 보고

TomTom은 Tele Atlas 맵 오류 보고 API를 구현하고 이것을 Tele Atlas로의 모든 보고들을 위한 보고 메커니즘으로서 사용하여야 할 것이다.

Claims

내비게이션 기기 상에 맵 데이터를 보충하는 방법에 있어서,

- 맵 데이터를 메모리로 로딩하는 단계;

- 차량의 위치, 속도 및 방향 중 적어도 하나를 계산하는 단계;

- 상기 맵 데이터 및 상기 위치와 상기 속도와 상기 방향 중 적어도 하나 사이에 불일치가 있는지 여부를 결정하는 단계;

- 불일치의 경우에, 상기 위치, 상기 속도 및 상기 방향 중 적어도 하나에 기초하여 맵 정정 데이터를 생성하는 단계; 및

- 불일치가 없는 경우에, 상기 맵 데이터의 정확성을 확인하는 단계를 포함하는 방법.
제1항에 있어서,

사용자 질의를 디스플레이하는 단계를 더 포함하는 방법.
제1항 또는 제2항에 있어서,

- 가능한 변경(alteration)들에 관한 메뉴구동형(menu driven) 선택을 제공하는 단계;

- 상기 변경들 중 적어도 하나를 포함하는 입력을 수신하는 단계; 및

- 상기 변경들 중 상기 적어도 하나를 포함하는 맵 정정 데이터를 생성하는 단계를 더 포함하는 방법.
제1항 내지 제3항 중 어느 한 항에 있어서,

- 상기 맵 데이터가 상기 위치를 포함하는지 여부를 결정하는 단계;

- 상기 맵 데이터가 상기 위치를 포함한다면, 상기 맵이 상기 현재 위치를 자동차 위치와 연관시키고 있는지 여부를 결정하는 단계; 및

- 상기 현재 위치가 자동차 위치와 연관되지 않으면, 정정 질의를 생성하는 단계를 더 포함하는 방법.
제1항 내지 제4항 중 어느 한 항에 있어서,

목적지로의 경로를 계획하는 단계를 더 포함하는 방법.
제5항에 있어서,

상기 결정하는 단계는 상기 위치, 상기 속도 및 상기 방향 중 적어도 하나를 상기 계획된 경로에 대해 비교하는 단계를 더 포함하는, 방법.
제5항에 있어서,

- 상기 차량이 상기 경로로부터 벗어나 있는지 여부를 결정하는 단계;

- 상기 차량이 상기 경로로부터 벗어났다면, 상기 차량이 벗어난 경로 부분을 결정하는 단계; 및

- 상기 경로 부분이 블록(block)되어야 하는지 여부를 사용자에게 질의하는 단계를 더 포함하는 방법.
제1항 내지 제7항 중 어느 한 항에 있어서,

- 변경된 맵 데이터를 포함한 경로를 계획하는 단계;

- 상기 차량이 상기 경로를 따랐는지 여부를 결정하는 단계;

- 상기 차량이 상기 경로를 따랐다면, 사용자 경로 만족에 관한 확인 질의(confirmation query)를 생성하는 단계;

- 상기 질의에 대한 응답을 수신하는 단계; 및

- 상기 응답을 원격 서버로 전송하는 단계를 더 포함하는 방법.
제1항 내지 제8항 중 어느 한 항에 있어서,

- 맵 데이터를 포함한 경로를 계획하는 단계;

- 상기 차량이 상기 경로를 따랐는지 여부를 결정하는 단계;

- 상기 차량이 상기 경로를 따랐다면, 사용자 경로 만족에 관한 확인 질의를 생성하는 단계;

- 상기 질의에 대한 응답을 수신하는 단계; 및

- 상기 응답을 서버로 전송하는 단계를 더 포함하는 방법.
제1항 내지 제9항 중 어느 한 항에 있어서,

- 주어진 시간 기간에 걸쳐 차량의 위치를 결정하는 단계;

- 상기 위치의 위치 속도 제한을 결정하는 단계;

- 상기 차량의 차량 속도 제한을 결정하는 단계;

- 문턱(threshold) 위치 속도 제한을 결정하는 단계;

- 상기 차량 속도 제한과 상기 문턱 위치 속도 제한을 비교하는 단계; 및

- 상기 차량 속도 제한이 상기 문턱 제한을 초과하면, 상기 위치 속도 제한을 변경하기 위한 사용자 질의를 생성하는 단계를 더 포함하는 방법.
제1항 내지 제10항 중 어느 한 항에 있어서,

- 현재 맵과 비현재 맵의 업데이트들을 비교하는 단계; 및

- 상기 업데이트들이 상기 현재 맵 상에 위치해 있지 않으면, 상기 업데이트들을 포함한 현재 맵 정정을 생성하는 단계를 더 포함하는 방법.
제1항 내지 제11항 중 어느 한 항에 있어서,

상기 맵 데이터와 별도로 상기 맵 정정 데이터를 저장하는 단계를 더 포함하는 방법.
제1항 내지 제12항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 분류하는 단계를 더 포함하는 방법.
제1항 내지 제13항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 원격 서버에 업로딩하는 단계를 더 포함하는 방법.
제1항 내지 제14항 중 어느 한 항에 있어서,

상기 맵 정정 데이터는 추가된 거리, 블록된 거리, 변경된 교통 방향, 변경된 회전 제한, 변경된 차량 유형 제한, 변경된 속도 제한 및 변경된 평균 속도 중 적어도 하나를 포함하는, 방법.
맵 데이터를 보충하는 내비게이션 기기에 있어서,

- 맵 데이터를 로딩하는 메모리;

- 차량의 위치, 속도 및 방향 중 적어도 하나를 계산하는 프로세서;

- 상기 맵 데이터 및 상기 위치와 상기 속도와 상기 방향 중 적어도 하나 사이에 불일치가 있는지 여부를 결정하는 수단; 및

- 불일치의 경우에 상기 위치, 상기 속도 및 상기 방향 중 적어도 하나에 기초하여 맵 정정 데이터를 생성하는 수단을 포함하는 내비게이션 기기.
제16항에 있어서,

사용자 질의를 디스플레이하는 디스플레이를 더 포함하는 내비게이션 기기.
제16항 또는 제17항에 있어서,

- 가능한 변경(alteration)들에 관한 메뉴구동형(menu driven) 선택을 제공하는 수단;

- 상기 변경들 중 적어도 하나를 포함하는 입력을 수신하는 수단; 및

- 상기 변경들 중 상기 적어도 하나를 포함하는 맵 정정 데이터를 생성하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제18항 중 어느 한 항에 있어서,

- 상기 맵 데이터가 상기 위치를 포함하는지 여부를 결정하는 수단;

- 상기 맵 데이터가 상기 위치를 포함한다면, 상기 맵이 상기 현재 위치를 자동차 위치와 연관시키고 있는지 여부를 결정하는 수단; 및

- 상기 현재 위치가 자동차 위치와 연관되지 않으면, 정정 질의를 생성하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제19항 중 어느 한 항에 있어서,

목적지로의 경로를 계획하는 수단을 더 포함하는 내비게이션 기기.
제20항에 있어서,

상기 결정하는 수단은 상기 위치, 상기 속도 및 상기 방향 중 적어도 하나를 상기 계획된 경로에 대해 비교하는 수단을 더 포함하는, 내비게이션 기기.
제20항 또는 제21항에 있어서,

- 상기 차량이 상기 경로로부터 벗어나 있는지 여부를 결정하는 수단;

- 상기 차량이 상기 경로로부터 벗어났다면, 상기 차량이 벗어난 경로 부분을 결정하는 수단; 및

- 상기 경로 부분이 블록(block)되어야 하는지 여부를 사용자에게 질의하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제22항 중 어느 한 항에 있어서,

- 변경된 맵 데이터를 포함한 경로를 계획하는 수단;

- 상기 차량이 상기 경로를 따랐는지 여부를 결정하는 수단;

- 상기 차량이 상기 경로를 따랐다면, 사용자 경로 만족에 관한 확인 질의(confirmation query)를 생성하는 수단;

- 상기 질의에 대한 응답을 수신하는 수단; 및

- 상기 응답을 원격 서버로 전송하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제23항 중 어느 한 항에 있어서,

- 맵 데이터를 포함한 경로를 계획하는 수단;

- 상기 차량이 상기 경로를 따랐는지 여부를 결정하는 수단;

- 상기 차량이 상기 경로를 따랐다면, 사용자 경로 만족에 관한 확인 질의를 생성하는 수단;

- 상기 질의에 대한 응답을 수신하는 수단; 및

- 상기 응답을 서버로 전송하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제24항 중 어느 한 항에 있어서,

- 주어진 시간 기간에 걸쳐 차량의 위치를 결정하는 수단;

- 상기 위치의 위치 속도 제한을 결정하는 수단;

- 상기 차량의 차량 속도 제한을 결정하는 수단;

- 문턱(threshold) 위치 속도 제한을 결정하는 수단;

- 상기 차량 속도 제한과 상기 문턱 위치 속도 제한을 비교하는 수단; 및

- 상기 차량 속도 제한이 상기 문턱 제한을 초과하면, 상기 위치 속도 제한을 변경하기 위한 사용자 질의를 생성하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제25항 중 어느 한 항에 있어서,

- 현재 맵과 비현재 맵의 업데이트들을 비교하는 수단; 및

- 상기 업데이트들이 상기 현재 맵 상에 위치해 있지 않으면, 상기 업데이트들을 포함한 현재 맵 정정을 생성하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제26항 중 어느 한 항에 있어서,

상기 맵 데이터와 별도로 상기 맵 정정 데이터를 저장하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제27항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 분류하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제28항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 원격 서버에 업로딩하는 수단을 더 포함하는 내비게이션 기기.
제16항 내지 제29항 중 어느 한 항에 있어서,

상기 맵 정정 데이터는 추가된 거리, 블록된 거리, 변경된 교통 방향, 변경된 회전 제한, 변경된 차량 유형 제한, 변경된 속도 제한 및 변경된 평균 속도 중 적어도 하나를 포함하는, 내비게이션 기기.
맵 데이터를 보충하는 내비게이션 기기에 있어서,

- 맵 데이터를 로딩하는 메모리;

- 차량의 위치, 속도 및 방향 중 적어도 하나를 계산하는 프로세서;

- 상기 맵 데이터 및 상기 위치와 상기 속도와 상기 방향 중 적어도 하나 사이에 불일치가 있는지 여부를 결정하는 수단; 및

- 불일치가 없는 경우에 상기 맵 데이터의 정확성을 확인하는 수단을 포함하는 내비게이션 기기.
제31항에 있어서,

사용자 질의를 디스플레이하는 디스플레이를 더 포함하는 내비게이션 기기.
제31항 또는 제32항에 있어서,

목적지로의 경로를 계획하는 수단을 더 포함하는 내비게이션 기기.
제33항에 있어서,

상기 결정하는 수단은 상기 위치, 상기 속도 및 상기 방향 중 적어도 하나를 상기 계획된 경로에 대해 비교하는 수단을 더 포함하는, 내비게이션 기기.