KR20120084764A

KR20120084764A - 자동차 소프트웨어 애플리케이션들 및 서비스들의 중앙 관리

Info

Publication number: KR20120084764A
Application number: KR1020127012265A
Authority: KR
Inventors: 캄야르 모인자데; 레온 엘. 홍; 리 자오
Original assignee: 에어비퀴티 인코포레이티드.
Priority date: 2009-10-15
Filing date: 2010-10-13
Publication date: 2012-07-30
Also published as: CA2774055A1; BR112012007367A2; US8838332B2; BR112012007368A2; US8831824B2; JP2013509032A; TW201124292A; CN102597954A; KR20120081213A; AU2010306911A2; KR20120089317A; EP2488944A1; MX2012004331A; WO2011047056A1; AU2010306831B2; WO2011047052A1; EP2488944B1; JP2013509033A; AU2010306911A1; TW201128533A

Abstract

일 실시예에서, 네트워크 장치(network device, 222)는 이용 가능한 사용자 애플리케이션 프로그램들의 리스트(609)를 유지한다. 상기 네트워크 장치(222)는 명시된(specified) 자동차 제품(make) 및 모델에서 사용하기 위해 상기 이용 가능한 사용자 애플리케이션 프로그램들 중 적어도 하나를 승인하되, 상기 승인은 상기 자동차 OEM 또는 서비스 제공자들에 의하거나 대신에 의해 결정된다. 상기 네트워크 장치(222)는 상기 승인된 애플리케이션들을 식별하는 애플리케이션들의 제어 리스트(610)를 형성한다. 상기 네트워크 장치(222)는 특정 자동차에 다운로드(239)하기 위해 승인된 애플리케이션들의 상기 제어 리스트로부터 적어도 하나의 애플리케이션을 선택하되, 상기 선택은 상기 특정 자동차의 소유자에 의하거나 대신에 의해 이루어진다. 상기 네트워크 장치(222)는 상기 선택된 애플리케이션 프로그램을 상기 특정 자동차에 무선으로 다운로드하고(250), 상기 특정 자동차의 헤드 유닛(221)상에 상기 다운로드된 애플리케이션 프로그램이 인스톨되게 한다.

Description

자동차 소프트웨어 애플리케이션들 및 서비스들의 중앙 관리{Centralized management of motor vehicle software applications and services}

우선권 주장

본 출원은 다음 미국 출원들에 대해 우선권을 주장한다:

발명의 명칭이 'CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES'이고 2010년 5월 11에 출원된 출원 번호 12/777,989, 이는 발명의 명칭이 'CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES'이고 2010년 3월 22일에 출원된 미국 특허 출원 번호 12/729,207의 일부계속출원(continuation-in-part application)이고, 이는 발명의 명칭이 'CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES'이고 2009년 10월 15일에 출원된 미국 가출원(Provisional Application) 번호 61/252,066 및 발명의 명칭이 'CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES'이고 2009년 11월 12일에 출원된 미국 가출원 번호 61/260,781의 정규출원(non-provisional)이고, 각각은 그대로 참조로서 여기에 병합된다.

자동차(motor vehicle)는 사용자 인터페이스를 포함하는 "헤드 유닛(head unit)"을 구비할 수 있다. 사용자 인터페이스는 화면(screen), 스피커들, 마이크(microphone), 터치 스크린 및/또는 키패드 등과 같은 다양한 자원 요소들(resource components)을 포함할 수 있다. 스마트폰들 또는 다른 휴대폰들은 폰(phone)상에서 작동하는 다양한 애플리케이션들(applications)을 다운로드할 수 있다. 애플리케이션을 제어하기 위해, 및/또는 (영상 표시(visual display)를 보거나 오디오 출력(audio output)을 듣는 것과 같이) 어떤 방식으로든 애플리케이션을 이용하기 위해, 사용자는 폰의 사용자 인터페이스를 이용할 수 있다.

휴대폰으로부터 헤드 유닛으로의 애플리케이션들의 확장은 다양한 서비스 제공자들(service providers) 및 차량 제조자들(vehicle manufacturers)에 의해 제공되는 대중적인 특성이 되었다. 결과적으로, 사용자는 헤드 유닛에 의해 제공되는 더 좋은 사용자 인터페이스 요소들(예를 들어, 더 큰 화면 및 고품질 오디오 출력)을 이용할 수 있다. 원격 서버(remote server)에서 이용할 수 있는 서비스 제어 로직(service control logic)을 이용하는 헤드 유닛상에서 작동하는 휴대폰 애플리케이션들의 확장을 제어, 관리 및 중재하기 위한 메커니즘을 제공하는 것이 바람직하다.

또한 차량들은 애플리케이션들이 차량 자체상에 인스톨되는 것(휴대 장치(mobile device)상에 인스톨되는 것과 대조적임)을 가능하게 하는 요소들을 포함하도록 제조될 수 있다. 차량 인터페이스(vehicle interface)의 사용을 이 애플리케이션들로 제어, 관리 및 중재하는 것도 바람직하다.

다음은 본 발명의 일부 측면들의 기본 이해를 제공하기 위한 본 발명의 요약이다. 이 요약은 본 발명의 키/중요한 요소들을 인정하거나, 본 발명의 범위를 설명하려는 의도가 아니다. 그것의 유일한 목적은 본 발명의 일부 개념들을 뒤에 서술된 상세한 설명에 대한 서막으로서 간단한 형태로 서술하는 것이다.

일 실시예에서, 네트워크 장치(network device)는 차량 상태들에 대한 애플리케이션 작동 모드들의 맵핑을 저장하고, 예를 들어 상기 차량 상태들은 상기 차량이 작동(powered)되나 이동하지 않는 제1 상태 및 상기 차량이 이동하는 제2 상태이다. 상기 네트워크 장치는 상기 차량에 의해 작동하는 인터페이스를 이용하는 특정 애플리케이션을 위해 무선으로 전송되는 요청(상기 차량의 무선 전송기 또는 상기 차량에 연결된 휴대 장치에 의해 전송됨)을 수신한다. 상기 네트워크 장치는 상기 수신된 요청에 의해 명시된 애플리케이션 식별자를 상기 맵핑과 비교한다. 다음, 상기 네트워크 장치는 상기 비교에 따라 상기 차량 인터페이스의 부분(portion)을 식별하고, 상기 차량상의 제어 소프트웨어에게 신호를 보내 상기 특정 애플리케이션이 상기 차량 인터페이스의 상기 식별된 부분에만 접속을 허용하도록 한다. 상기 애플리케이션은 상기 휴대 장치상에 탑재되고, 상기 차량 인터페이스를 확장 인터페이스로 이용하거나, 상기 애플리케이션은 상기 차량 자체에 탑재될 수 있다. 본 발명의 추가적인 실시예들 및 장점은 최선의 실시예의 다음 상세한 설명으로부터 명백해지고, 동반된 도면을 참고하여 진행된다.

도 1은 안전하고 지능적인 방식으로 폰 애플리케이션을 위한 확장 인터페이스(extended interface)로 헤드 유닛의 사용을 제어하는 시스템을 나타낸다.
도 2a는 도 1의 소프트웨어(32)의 동작을 도시한 흐름도를 나타낸다.
도 2b는 도 1의 소프트웨어(30)에 의해 사용될 수 있는 경쟁 방식(contention scheme)을 도시한 흐름도를 나타낸다.
도 3은 도 1의 소프트웨어(30A-B)의 동작을 도시한 흐름도를 나타낸다.
도 4는 안전하고 지능적인 방식으로 차량에 애플리케이션들을 선택하고 분배(distribute)하는 시스템을 나타낸다.
도 5는 도 4의 소프트웨어의 동작을 도시한 흐름도를 나타낸다.
도 6은 도 4-5에 도시된 시스템을 더욱 상세하게 나타낸다.
도 7은 사용자 선호도들(user preferences)에 따라 안전하고 지능적인 방식으로 차량에 애플리케이션들을 선택하고 분배하는 시스템을 나타낸다.
도 8은 도 7의 소프트웨어의 동작을 도시한 흐름도를 나타낸다.
도 9는 도 7-8에 도시된 시스템을 더욱 상세하게 나타낸다.
도 10은 헤드 유닛의 설정에 따라 헤드 유닛 그래픽 인터페이스를 선택하는 시스템을 나타낸다.
도 11은 원격 컴퓨터 승인들(approvals)을 생성하고 헤드 유닛에 전송하는 시스템을 나타낸다.
도 12는 새로운 애플리케이션 또는 새로운 애플리케이션을 선택하는 사용자 웹 포털을 위한 요청을 생성하는 휴대 장치에 응답하여, 그래픽 사용자 인터페이스 업데이트들을 헤드 유닛에 밀어 넣는(push) 시스템을 나타낸다.
도 13a는 부모 제어 방식(parental control scheme)의 이전 동작(pre-operation)을 도시한 흐름도를 나타낸다.
도 13b는 부모 제어 방식의 동작을 도시한 흐름도를 나타낸다.

일 예에서, 사용자는 헤드 유닛(head unit)을 폰(phone)을 위한 확장 인터페이스(extended interface)로 사용할 목적으로 유선 또는 무선 연결을 사용하여 폰을 자동차 헤드 유닛(motor vehicle head unit)에 연결한다. 다음 단락에서 서술하는 바와 같이 원격 서버를 통한 결정에 따라, 사용자가 헤드 유닛의 인터페이스를 사용하여 폰상의 애플리케이션을 제어하는 것이 허용될 수 있다. 마찬가지로, 다음 단락에서 서술하는 바와 같이 원격 서버를 통한 결정에 따라, 사용자는 헤드 유닛의 인터페이스를 통해 애플리케이션의 출력을 보거나 듣는 것이 허용될 수 있다.

새로운(novel) 클라이언트는 폰상의 소프트웨어를 제어하고, 헤드 유닛은 폰으로부터 확장된 무선 연결을 통해 원격 서버상의 새로운(novel) 서버 제어 소프트웨어와 인터페이스한다. 클라이언트 제어 소프트웨어는 헤드 유닛을 확장 인터페이스로 이용하기 위해 폰 애플리케이션을 식별한다. 서버 제어 소프트웨어는 식별된(identified) 폰 애플리케이션을 원격 서버에 의해 접속 가능한 하나 이상의 데이터베이스들과 비교한다. 비교를 기반으로, 서버 제어 소프트웨어는 식별된 애플리케이션이 헤드 유닛을 확장 인터페이스로 이용하는 것이 허용되는지 여부를 결정하고, 만일 그렇다면, 헤드 유닛 인터페이스의 어느 요소들이 애플리케이션에 의해 사용되는 것이 허용되는지를 결정한다. 서버 제어 소프트웨어는 클라이언트 제어 소프트웨어에게 신호를 보내 결정에 따라 폰 및 헤드 유닛을 제어하도록 한다. 따라서, 헤드 유닛의 확장 인터페이스로의 임의의 이용은 안전하고 지능적인 방식으로 제어될 수 있다.

도 1은 안전하고 지능적인 방식으로 폰 애플리케이션을 위한 확장 인터페이스로 헤드 유닛의 사용을 제어하는 시스템을 나타낸다.

시스템(100)은 소프트웨어(30A, 30B)를 포함하고, 각각은 휴대폰(20)(또는 다른 휴대 장치) 및 헤드 유닛(21)(또는 자동차에 의해 작동되는 다른 인터페이스, 예를 들어, 핸들(steering wheel)에 집적된 사용자 인터페이스 또는 의자 뒷부분(seat back)에 집적된 사용자 인터페이스)상에 형성된다. 소프트웨어(30A, 30B)는 원격 서버(22) 상에 형성되어 있는 소프트웨어(32)와 인터페이스하여, 폰(20)상에서 작동하는 애플리케이션들(40)이 헤드 유닛(21)의 I/O 자원들(1-4)에 언제 어떻게 접속할지를 조절하고 제어한다.

도 2a는 도 1의 소프트웨어(32)의 동작을 도시한 흐름도를 나타낸다.

블록(201)에서, 소프트웨어(32)는 헤드 유닛(21)의 인터페이스(입력(24) 자원들(1-2) 및 출력(25) 자원들(3-4)을 포함)를 이용하기 위해 폰(20)상의 특정(particular) 애플리케이션(40)에 대한 요청(request)을 수신한다. 요청은 자동차 및/또는 헤드 유닛(21)의 사용자에 대응하는 사용자 식별자(user identifier), 특정 애플리케이션(40)에 대응하는 애플리케이션 식별자(application identifier) 및 차량 상태 정보(vehicle status information)를 포함한다. 사용자 식별자는 제어 소프트웨어(30A)가 휴대폰(100) 내에서 처음 활성화되면 사용자에 의해 제공되는 식별자, 사용자의 전화 번호 등일 수 있다.

블록(202)에서, 소프트웨어(32)는 사용자를 인증한다. 이것은 사용자 식별자에 의해 식별된 사용자가 헤드 유닛(21)을 사용하여 폰(20)의 인터페이스를 확장하는 서비스에 대한 가입자들의 데이터베이스(11)와 매치(match)하는지 여부를 결정하는 것을 포함할 수 있다. 마름모꼴 블록(203)에서 사용자가 인증되지 않으면, 블록(204A)에서 소프트웨어(32)는 소프트웨어(30A/B)에게 신호를 보내 애플리케이션(40)에 의한 헤드 유닛(21)으로의 접속을 차단하도록 한다. 블록(202)이 선택적이 되도록 시스템(100)이 형성될 수 있음이 이해되어야 한다.

이와 달리, 사용자가 인증되면, 블록(204B)에서 소프트웨어(32)는 애플리케이션 식별자를 애플리케이션들의 리스트(12)(화이트리스트(white liest)라고도 함)와 비교함으로써 애플리케이션(40)을 인증한다. 이 리스트(12)는 버전 번호(version number)에 의해 비교될 수 있어, 애플리케이션(40)의 하나의 특정 버전이 리스트상에서 식별될 수 있고, 다른 버전은 제외된다. 마름모꼴 블록(205)에서 특정 애플리케이션(40)(또는 특정 버전)이 리스트(12)상에 없다면, 블록(204A)에서 소프트웨어(32)는 소프트웨어(30A-B)에게 신호를 보내 애플리케이션(40)에 의한 헤드 유닛(21)으로의 접속을 차단하도록 한다

이와 달리, 애플리케이션(40)이 인증되면, 블록(206)에서 소프트웨어(32)는 애플리케이션 식별자 및 현재(current) 차량 상태 정보를 애플리케이션 작동 모드들의 맵핑(mapping, 15)과 비교한다. 도시한 바와 같이, 맵핑(15)은 리스트(12)의 각 애플리케이션(40)을 위한 항목(entry, 17)을 포함할 수 있다. 각 항목(17)은 대응하는 애플리케이션(40)을 위해 특정화된(particularized) 맵핑을 포함한다. 예를 들어, 애플리케이션 A를 위한 항목(17)은 차량 상태 "차량 이동≤X(vehicle moving ≤ than X)"를 자원들(1, 2, 4)에 맵핑한다(즉, 애플리케이션 A는 이 차량 상태 하에서 오직 화면(1), 스피커(2) 및 마이크(4)에 접속하는 것이 허용된다). 반면 애플리케이션 C를 위한 항목(17)은 차량 상태 "차량 이동≤X"를 오직 자원들(2, 4)에 맵핑한다(즉, 애플리케이션 C는 스피커(2) 및 마이크(4)에 접속하는 것이 허용된다). 하나의 실제 예시는 내비게이션 애플리케이션 A, 비디오 게임 애플리케이션 C일 수 있고, 승객(passenger)이 존재하더라도 시스템(100)은 비디오 게임 애플리케이션 C가 헤드 유닛(21) 화면(1)상에 디스플레이되는 것을 허용하지 않는데, 이는 운전자(driver)의 집중을 너무 많이 방해하는 것으로 여겨지기 때문이다. 반면 내비게이션 애플리케이션 A는 헤드 유닛(21) 화면(1)상에 디스플레이될 수 있다. 다른 실제 애플리케이션은 헤드 유닛 및 좌석 뒤에 부착된 디스플레이와 같은 복수의 인터페이스들을 포함하는 차량일 수 있다. 애플리케이션은 동일한 애플리케이션이 헤드 유닛에의 접속이 승인되지 않는 상태들 하에서 뒷좌석 디스플레이(back seat display)에 접속은 승인될 수 있다.

다른 예들에서, 맵핑(15)이 휴대폰(20)상에 저장될 수 있음이 이해되어야 한다. 이 경우에, 이전 단락에서 설명된 비교는 제어 소프트웨어(30A)에서 수행될 수 있다. 이러한 경우에, 제어 소프트웨어(30A)는 헤드 유닛(21)과의 통신을 통해 현재 차량 상태를 체크한다.

블록(207)에서, 소프트웨어(32)는 비교에 따라 헤드 유닛(21)의 I/O 자원들의 일부 또는 모두의 집합을 식별한다. 블록(208)에서, 소프트웨어(32)는 원격 소프트웨어(remote software)에게 신호를 보내 오직 식별된 집합의 I/O 자원들(1-4) 중의 자원들에의 특정 애플리케이션(40) 접속을 제공하도록 한다. 일 예에서, 그러한 신호(signaling)는 휴대폰(20)상에서 소프트웨어(30A)를 제어하는 것을 포함할 수 있어, 휴대폰(20)으로부터 전송된 모든 접속 요청들은 I/O 자원들의 식별된 집합에 따른다. 다른 예에서, 그러한 신호는 헤드 유닛(21)상의 I/O 자원들을 단순히 불능시키는 것과 같은 임의의 방법으로 휴대폰(20)으로부터 전송된 접속 요청들을 차단하기 위해, 헤드 유닛(21)상에서 소프트웨어(30B)를 제어하는 것을 포함할 수 있다. 또 다른 예들에서, 그러한 신호는 소프트웨어(30A) 및 소프트웨어(30B) 모두를 제어하는 것을 포함할 수 있다.

도 2b는 도 1의 소프트웨어(30B)에 의해 사용될 수 있는 경쟁 방식(contention scheme)을 도시한 흐름도를 나타낸다. 경쟁 방식은 도 2a에 도시된 방식에 더하여 이용될 수 있다.

블록(209)에서, 소프트웨어(30B)는 식별된 집합의 I/O 자원들 중 임의의 자원이 현재 사용 중(currently in use)인지 여부를 결정한다. 마름모꼴 블록(210)에서 어느 것도 사용 중이 아니면, 블록(211A)에서 소프트웨어(30B)는 오직 식별된 집합의 I/O자원들에의 특정 애플리케이션 접속을 제공한다.

이와 달리, 집합의 자원들 중 적어도 하나가 사용 중이면, 블록(211B)에서 소프트웨어(30B)는 식별된 집합의 사용 중인 자원들 각각을 위한 애플리케이션들의 자원별(by-resource) 랭킹(ranking, 13)을 식별한다. 이는 각 자원들(1-4)을 위한 랭킹(13)이 존재하는 것으로 도 1에 도시되어 있다.

블록(212)에서, 소프트웨어(30B)는 애플리케이션 식별자를 자원별 랭킹(들)(13)과 비교하여, 애플리케이션(40)이 식별된 서브집합(subset)의 사용 중인 자원들 중 임의의 자원에 대해 우선권(priority)을 갖는지 여부를 결정한다(랭킹(13)은 원격 서버상에 나타나기 때문에 이는 신호를 통해 수행될 수 있다. 또는 랭킹은 이전 프로세스에서 차량 인터페이스로 전송되었을 수도 있다). 이 비교는 특정 사용 중인 자원을 현재 사용하는 애플리케이션이 그 사용 중인 자원에 대한 요청 애플리케이션(requesting application)보다 높거나 낮은 우선권으로 여겨지는지 여부를 지시한다. 블록(213)에서, 소프트에어(30B)는 식별된 집합의 I/O 자원들(1-4) 중 오직 현재 사용 중이 아니거나, 낮은 우선권의 애플리케이션에 의해 사용 중인 자원들에의 특정 애플리케이션(40) 접속을 제공한다.

도 3은 도 1의 소프트웨어(30A-B)의 동작을 도시한 흐름도를 나타낸다.

블록(301)에서, 소프트에어(30A-B)는 헤드 유닛(21)의 인터페이스를 이용하기 위해 폰(20)상의 특정 애플리케이션(40)을 위한 요청을 전송한다. 블록(302)에서, 소프트웨어(30A-B)는 애플리케이션(40)이 이때 헤드 유닛(21)에의 접속을 인가받는지 여부를 지시하는 신호를 수신하고, 만일 그러하다면, 식별된 자원들(1-4)이 이용될 수 있다. 마름모꼴 블록(303)에서 애플리케이션(40)이 인가받지 못하면, 블록(304A)에서 소프트웨어(30A-B)는 애플리케이션(40)이 헤드 유닛에의 접속을 인가받지 못했다는 알림(notification)을 출력한다. 이 알림은 휴대폰(20), 헤드 유닛(21) 또는 둘 다를 통해 출력될 수 있다.

이와 달리, 마름모꼴 블록(303)에서 애플리케이션(40)이 인가받으면, 블록(304B)에서 소프트웨어(30A-B)는 휴대폰(20) 및 헤드 유닛(21)을 제어하여, 애플리케이션(40)이 식별된 자원들로 확장되도록 한다. 충돌 때문에 애플리케이션(40)을 위한 (각각의 맵핑(17)으로부터) 가능한 자원들의 서브집합만이 이용된다면, 소프트웨어(30A-B)는 알림을 생성할 수 있어, 운전자에게 높은 우선권의 애플리케이션이 활성화되기 전에 낮은 우선권의 애플리케이션이 중단됨(being suspended)을 알린다. 다른 예에서, 자원들이 낮은 우선권의 애플리케이션에 의해 현재 사용된다면, 소프트웨어(30A-B)는 자동적으로 낮은 우선권 애플리케이션을 중단/종료(suspend/end)할 수 있고, 요청된 자원들을 사용하여 높은 우선권의 애플리케이션을 활성화시킬 수 있다.

애플리케이션(40)이 헤드 유닛(21)으로 확장될 수 있다고 결정되면, 서버(22)는 애플리케이션(40)을 제어하기 위해 대응되는 "제어 패널(control panel)" 소프트웨어를 헤드 유닛으로 다운로드할 수 있다. 요청된 애플리케이션을 기반으로 이 소프트웨어를 헤드 유닛(21)으로 다운로드함으로써, 서비스 제공자는 새로운 애플리케이션들 또는 존재하는 애플리케이션들의 업데이트가 이용할 수 있는 시기에 맞춰 서비스 제공자는 "제어 패널"을 원하는 대로 바꾸거나(customize) 업데이트할 수 있다. 헤드-유닛은 "제어 패널" 소프트웨어를 디스플레이하기 위해 웹-코드 렌더러(web-code renderer)를 포함할 수 있다.

다시 도 1을 참고하면, 소프트웨어(30A-B)는 휴대폰(20)으로부터 확장된 무선 연결을 통해 소프트웨어(32)와 인터페이스한다. 이 무선 연결은 (GPRS, EDGE, EVDO, UTMS, WiMAX, WiFi 등을 포함하나 이에 제한되지 않는) 패킷 데이터 연결, 단문메시지서비스(Short Message Service; SMS), 또는 휴대폰(20)상의 대역 내 신호 방식 모뎀들(In-Band-Signaling modems) 및 미국 특허 6,144,336; 6,690,681; 및 6,493,338에서 기술된 원격 서버(22)를 이용할 수 있다.

계속 도 1을 참고하면, 휴대폰(20)은 USB, 블루투스 또는 WiFi 연결과 같은 연결을 사용함으로써 헤드 유닛(21)에 연결될 수 있음을 유의한다. 그러나, 이는 단지 예시들이고, 다른 경우에는 다른 연결 및/또는 프로토콜이 휴대폰(20)의 애플리케이션(40)을 위한 헤드 유닛(21)의 인터페이스를 이용하기에 적합할 수 있다.

맵핑(15)은 임의의 차량 상태들을 가질 수 있고, 4개의 도시된 예들은 단지 예시임이 이해되어야 한다. 예를 들어, 다른 차량 상태는 차량이 속도 'X'보다 빠르게 이동하고, 그리고 승객이 존재하는 것일 수 있다.

헤드 유닛(21)이 도시된 모든 예시 자원들보다 적게 포함할 수 있거나, 도시되지 않은 다른 자원들을 포함할 수 있음이 이해되어야 한다. 예를 들어, 다른 가능한 I/O 자원 요소는 스피치 요소(speech component)에 대한 텍스트(text)이다.

도시된 예에서, 제1 애플리케이션은 시스템(100)에 의한 지능적 결정을 기반으로 헤드 유닛(21)상에 실제로 존재하는 임의의 자원들의 제1 서브집합에의 접속이 허용될 수 있고, 다른 제2 애플리케이션은 자원들의 제2 서브집합 또는 자원들 모두에의 접속이 허용될 수 있다.

애플리케이션들(40)은 도시된 것과 같이 "자원별(by resource)"로 랭크(rank)될 수 있거나, 모든 애플리케이션들(40)을 포함하는 단일 랭킹(single ranking)이 존재할 수 있음이 이해되어야 한다. 시스템(100)은 도시된 "자원별" 랭킹과 함께 구현되나, 여기서 기술된 개념들은 자원에 독립적으로 애플리케이션들을 랭크하는 다른 시스템에서 구현될 수도 있다.

도 4는 안전하고 지능적인 방식으로 차량에 애플리케이션들을 선택하고 분배하는 시스템을 나타낸다.

도 1에서 이미 기술된 시스템 및 도 4의 시스템의 하나의 차이점은 애플리케이션들의 인스톨 위치(install location)이다. 도 1의 시스템(100)에서 애플리케이션들(A-C)은 (확장 인터페이스로 헤드 유닛(21) 또는 차량에 의해 작동되는 다른 인터페이스를 사용하는) 휴대폰(20)상에서 인스톨되고 동작하는 반면, 도 4의 시스템(200)에서 애플리케이션들(J-L)은 헤드 유닛(221) 또는 차량에 의해 작동되는 다른 요소(component)상에서 인스톨된다. 도 4의 시스템(200)에서, 소프트웨어(230-232)는 제공자가 헤드 유닛(221)상에서 인스톨될 수 있는 애플리케이션들을 선택하게 할 수 있고, 차량에 선택된 애플리케이션들의 분배(distribution)를 제어하게 할 수 있다.

다음 단락들에서 시스템(200)의 세부 사항을 설명하기 전에, 도 1 내지 도 3에 기술된 시스템(100)의 구조들 및 기능들은 시스템(200)(도 4-6)의 구조들 및 기능들과 단일 시스템(single system)으로 결합될 수 있음이 명백하다. 예를 들어, 단일 시스템은 확장 인터페이스로 차량의 인터페이스를 사용하는 휴대폰상에 인스톨되는 일부 애플리케이션들 및 차량의 요소상에 인스톨되는 일부 애플리케이션들을 포함할 수 있다.

도 5는 도 4의 소프트웨어의 동작을 도시한 흐름도를 나타낸다.

블록(501)에서, 차량이 파워 업(power up)되는 것에 응답하여, 제어 소프트웨어(230)는 차량 파워-업(vehicle power-up)을 지시하는 신호(244)를 서버(222)에 전송한다. 신호(244)는 USB 또는 블루투스 연결과 같은 로컬 연결(local connection)을 통해 전송될 수 있어, 무선 통신 네트워크상에서 휴대 장치(220)에 의해 중계된다.

블록(502)에서, 소프트웨어(232)는 차량에 연관된 다운로드 디렉토리(239)(종종 "샌드박스(sandbox)"라고도 함)를 검사하여, 차량에 다운로드된 임의의 애플리케이션이 존재하는지 여부를 결정한다. 다운로드 디렉토리(239)에 존재하는 애플리케이션들을 지능적으로 선택하기 위한 방식은 도 6을 참고하여 뒤에서 상세하게 설명된다.

소프트에웨어(232)에 의한 검사가 다운로드 디렉토리(239)가 적어도 하나의 애플리케이션을 포함함을 지시하면, 프로세스가 계속된다. 우선, 도시의 목적으로 다운로드 디렉토리(239)가 애플리케이션들(240, J-L)을 포함하는 것으로 가정한다. 따라서, 블록(503)에서 소프트웨어(232)는 신호(245)를 생성하고 전송하여, 휴대폰(220)상의 IP 게이트웨이(gateway) 소프트웨어(231)가 헤드 유닛(221)에 애플리케이션을 전달하기 위한 IP 게이트웨이로 동작하도록 한다. 일 예에서, 신호(245)는 블록(502)에서의 결정에 응답하여 휴대폰(220)에 소프트웨어(231)를 동적으로 로드하고(dynamically load), 소프트웨어(231)가 차량에의 다운로드를 위해 휴대폰상에서 동작하도록 하는 통신들을 포함한다. 휴대폰(220)에 소프트웨어(231)가 이미 로드되고, IP 게이트웨이 동작이 준비되면, 신호(245)는 발생되지 않을 수 있다. 다른 예들에서, 신호(245)는 차량 파워-업 검출에 응답하여 헤드 유닛(221)상의 제어 소프트웨어(230)로부터 유래할 수도 있다.

블록(504)에서, 소프트웨어(232)는 IP 패킷들(250)을 생성하고 전송하여, 차량으로 애플리케이션들을 다운로드한다. IP 패킷들(250)은 휴대폰(220)에 의해 수신되고, 소프트웨어(231)의 동작에 의해 헤드 유닛(221)으로 전달된다. 블록(505)에서, 소프트웨어(230)는 IP 패킷들(230)을 수신하고, 애플리케이션들(240, J-L)을 차량상에 인스톨한다(인스톨은 헤드 유닛(221)의 요소들 또는 다른 차량 요소들상에 가능함).

그 후에, 차량의 사용자는 인터페이스로 헤드 유닛(221)을 사용하여 애플리케이션들(J-L)을 조작할 수 있다. 소프트웨어(230, 232)는 도 1-3에 기술된 원리들 중 임의의 원리에 따라 동작할 수 있음이 이해되어야 한다. 예를 들어, 소프트웨어(230, 232)는 현재 차량 상태에 따라 활성화된(active) 애플리케이션(들)에 의한 헤드 유닛(221)의 I/O 자원들의 이용을 조절할 수 있다. 다른 예로서, 애플리케이션들이 차량 및 휴대 장치 모두에 인스톨되는 시스템들에서, 소프트웨어(230, 232)는 테이블(도 1의 13)과 유사한 애플리케이션 랭킹/우선권 테이블(application ranking/priority table) 내의 차량 인터페이스를 이용하는 모든 애플리케이션들을 포함할 수 있다.

일 예에서, 헤드 유닛(221)은 소프트웨어(230)를 통해 제어되는 웹 코드 렌더러(web code renderer, 299)(예를 들어 HTML 렌더러)를 포함한다. 웹 코드 렌더러(299)는 HTML 코드를 디스플레이하도록 구성되나, 브라우저(browser)와 달리 사용자가 웹 위치들(web locations)을 자유롭게 돌아다니는 것을 허용하지는 않는다. 특별히, 웹 코드 렌더러(299)는 제공자에 의해 허용된, 즉 서버(222)에 의해 특정된, 애플리케이션만을 디스플레이한다.

위에서 기술된 흐름도는 차량상에 인스톨되는 애플리케이션들의 업데이트를 다루는 것으로 이해되어야 한다. 또한 차량에는 특정(certain) 애플리케이션들이 미리 로드(pre-load)될 수 있어, 차량상에 인스톨된 애플리케이션들의 일부는 흐름도에 따라 다운로드되고, 다른 것들은 제조되는 동안(during manufacturing) 차량상에 인스톨된다.

따라서, 위에서 기술된 원리들을 기반으로, 차량들은 차량상에 아무런 애플리케이션들이 인스톨되지 않도록 제조될 수 있고, 대신에 운전자들이 차량들 내에 있으면 애플리케이션들이 차량에 다운로드될 수 있다. 차량들에 다운로드되는 애플리케이션들의 유형들(types)은 운전자들에 의해 제공되어 네트워크 서버 내에 정의된 선호도들(preferences)에 의해 통제된다.

도 6은 도 4-5에 도시된 시스템을 더욱 상세하게 나타낸다.

서버(222)가 차량 단위마다(per-vehicle basis) 다운로드되기 위해 대기하는 애플리케이션들의 다운로드 디렉토리(239)를 포함하는 것은 이미 설명되었다. 도 6은 다운로드 디렉토리(239) 내 애플리케이션들의 선택과 연관(involve)될 수 있는 사용자 웹 포털들(user web portals, 601, 604, 605)을 나타내고, 이 웹 포털들(601, 604, 605)의 사용예를 표현한다.

차량의 OEM과 같은 제공자는 웹 포털(601)을 운용한다(operate). 컴퓨터 터미널(computing terminal, 625)과 같은 인터페이스를 사용하는 제공자는 통신들(650)과 함께 웹 포털(601)의 애플리케이션 선택 부분(portion)(608)을 제어하여, 차량상에 인스톨될 수 있는 모든 애플리케이션들의 리스트(609)로부터 애플리케이션들의 제어 리스트(controlled list)(610)를 조립한다(assemble). 리스트(609)로부터 리스트(610)의 일반적인 조립(typically building)은 제공자의 기술적 관점(technical standpoint) 및/또는 비즈니스 관점(business standpoint)으로부터 애플리케이션들의 검증(validation)과 연관된다.

제공자는 또한 통신들(651)을 전송하여, 제어 리스트(610)로부터 특정 차량상에 인스톨되는 애플리케이션들을 선택한다. 예를 들어, 이 선택들은 애플리케이션들에 대한 차량 모델들(vehicle models)의 맵핑을 기반으로 할 수 있다. 이 선택들(652)은 다운로드 디렉토리(239)로 공급된다.

이용 가능한 모든 애플리케이션들의 리스트(609)에 관하여, 이 리스트는 제공자 및/또는 제3자들(third parties)에 의해 개발된 애플리케이션들에 의해 조립될 수 있음이 이해되어야 한다. 제3자들이 애플리케이션들을 제공하는 경우에는, 제3자는 (일 예에서 제공자에 의해 운용되는 웹 서버에 의해 관리(host)되는) 웹 포털(604)의 애플리케이션 제출(submission)(618) 부분을 사용하여, 리스트(609)에 포함되도록 애플리케이션를 제출한다(649).

차량 사용자는 또한 컴퓨터 터미널(626)(예를 들어 휴대 장치 또는 데스크톱 컴퓨터와 같은 임의의 인터넷 접속 가능한 컴퓨터 장치)을 사용하여 다운로드 디렉토리(239)에 포함되도록 애플리케이션들을 선택할 수 있다. 컴퓨터 터미널(626)은 (일 예에서 제공자에 의해 운용되는 웹 서버에 의해 관리되는) 사용자 웹 포털(605)의 애플리케이션 선택 부분(628)에 접속하여, 그의 차량상에 인스톨될 수 있는 애플리케이션들의 제어 리스트(610)를 보여준다. 다음, 사용자는 통신들(661)을 전송하여, 제어 리스트(610)로부터 사용자가 그의 차량상에 인스톨하고자 하는 애플리케이션들을 선택한다. 이 선택들(662)은 다운로드 디렉토리(239)로 공급된다.

사용자 웹 포털(605)은 또한 사용자가 다운로드 디렉토리(239)로부터 특정 애플리케이션들을 삭제할 수 있도록 구성될 수 있다. 예를 들어, 사용자는 제공자를 통해 다운로드 디렉토리(239)에 추가된 제공자 선택 애플리케이션들(provider selected applications)(652) 중 하나를 삭제하고 싶을 수 있다. 삭제는 디렉토리(239)에 미리 전송된 애플리케이션의 삭제를 통해서나, 다운로드 디렉토리(239)에 애플리케이션이 추가되기 전에 원치 않는 특정 애플리케이션을 지시함으로써 이루어질 수 있다.

위에 따르면, 애플리케이션들은 차량마다(per-vehicle) 다운로드 디렉토리(239)에 축적(accumulate)될 수 있다. 차량 파워-업 시, 그러한 애플리케이션들은 다운로드될 수 있고, 차량상에 인스톨될 수 있다. 다음, 다운로드 디렉토리(239)는 다음 차량 파워 업 시까지 새로운 애플리케이션들을 축적할 수 있다.

웹 포털(605)의 인터페이스와 유사한 인터페이스가 차량의 헤드 유닛상에 디스플레이될 수 있음이 이해되어야 한다. 다음, 사용자는 제어 리스트(610)로부터 애플리케이션들을 선택하기 위해 그러한 인터페이스로부터 선택들을 할 수 있다. 인터페이스로부터 선택들이 이루어지면, 선택된 애플리케이션들은 다운로드 디렉토리에 들어가는 대신 즉시 차량에 다운로드될 수 있다.

도 7은 사용자 선호도들(user preferences)에 따라 안전하고 지능적인 방식으로 차량에 애플리케이션들을 선택하고 분배하는 시스템을 나타낸다.

도 1에서 이미 기술된 시스템 및 도 7의 시스템의 하나의 차이점은 애플리케이션들의 인스톨 위치이다. 도 1의 시스템(100)에서 애플리케이션들(A-C)은 (확장 인터페이스로 헤드 유닛(21) 또는 차량에 의해 작동되는 다른 인터페이스를 사용하는) 휴대폰(20)상에서 인스톨되고 동작하는 반면, 도 7의 시스템(300)에서 애플리케이션들(M-P/Q-S)은 헤드 유닛(321) 또는 차량에 의해 작동되는 다른 요소상에서 인스톨된다. 도 7의 시스템(300)에서, 소프트웨어(330-332)는 제공자가 헤드 유닛(221)상에서 인스톨될 수 있는 애플리케이션들을 선택하게 할 수 있고, 차량에 선택된 애플리케이션들의 분배를 제어하게 할 수 있다.

다음 단락들에서 시스템(300)의 세부 사항을 상세하게 설명하기 전에, 도 1 내지 도 6에 기술된 시스템(100, 200)의 구조들 및 기능들은 시스템(300)(도 7-8)의 구조들 및 기능들과 단일 시스템으로 결합될 수 있음이 명백하다. 예를 들어, 단일 시스템은 확장 인터페이스로 차량의 인터페이스를 사용하는 휴대폰상에 인스톨되는 일부 애플리케이션들 및 차량의 요소상에 인스톨되는 일부 애플리케이션들을 포함할 수 있다.

도 8은 도 7의 소프트웨어의 동작을 도시한 흐름도를 나타낸다.

블록(801)에서, 헤드 유닛(321)이 휴대폰(320)과 같은 휴대 장치에 통신에 관하여(communicatively) 연결된다. 일 예에서, 연결(540)은 헤드 유닛(321)과 휴대폰(320)의 블루투스 페어링(Bluetooth pairing)을 통해 설정된다. 휴대폰(320)의 파워 업, 휴대폰(320)이 헤드 유닛(321)의 범위 내에 들어오는 것, 다른 블루투스 장치가 헤드 유닛(321)으로부터 분리된 후 리페어링(re-pairing) 등과 같이 다른 상황에 의해 블루투스 페어링이 발생될 수 있음이 명백하더라도, 블루투스 페어링은 (헤드 유닛이 파워 업되고 블루투스 장치를 검색하게 하는) 차량의 파워 업에 대한 응답일 수 있다. 다른 예들에서, 통신 연결(communicative connection)은 사용자가 USB 연결을 사용하여 휴대폰(320)을 헤드 유닛(321)에 연결함으로써 설정될 수 있다.

블록(802)에서, 제어 소프트웨어(330)는 휴대폰(320)의 전화 번호에 접속한다. 휴대폰들은 콜 플랜(call plan)에 가입과 결합된 특정 전화 번호에 의해 활성화되고, 이는 제어 소프트웨어(330)가 휴대폰(320)으로부터 독출한 전화 번호인 것이 이해되어야 한다. 일 예에서, 전화 번호를 획득하기 위한 신호(542)는 블루투스 신호를 이용하여 수행된다.

블록(803)에서, 제어 소프트웨어(330)는 서버(322)에 신호(543)를 전송한다. 신호(543)는 USB, 블루투스 또는 WiFi 연결과 같은 로컬 연결을 통해 전송될 수 있어, 무선 통신 네트워크상에서 휴대 장치(320)에 의해 중계된다. 신호(543)의 내용(content)은 도 4와 관련하여 이전에 상세하게 설명한 신호(244)와 유사하나, 추가로 획득된 전화 번호를 제공할 수 있다.

블록(804)에서, 제어 소프트웨어(332)는 신호(543)에 포함되는 전화 번호를 맵핑(350)과 비교한다. 맵핑은 이 특정 헤드 유닛(32)을 통해 접속 가능한 복수의 다운로드 디렉토리들(A-B) 각각과 특정 전화 번호 사이의 연관성을 나타낸다(correlate). 예를 들어, 맵핑에서 제1 전화 번호는 다운로드 디렉토리 A와 연관성이 있고, 제2 전화 번호는 다운로드 디렉토리 B와 연관성이 있다. 제어 소프트웨어(332)는 수신된 전화 번호와 맵핑(350)의 비교를 기반으로 다운로드 디렉토리들(A-B) 중 하나를 선택한다.

다음, 소프트웨어(332)는 다운로드 디렉토리들(A-B) 중 선택된 하나를 검사하여, 선택된 디렉토리에 현재 저장되어 있는 임의의 애플리케이션들이 존재하는지 여부를 결정한다. 다운로드 디렉토리들(A-B)에 존재하는 애플리케이션들을 지능적으로 선택하기 위한 방식은 도 9를 참고하여 뒤에서 상세하게 설명된다. 우선, 도시의 목적으로 헤드 유닛 프론트엔드 설정들(head unit frontend configurations)(369A, 369B)에 더해, 다운로드 디렉토리들(339A, 339B)이 각각 애플리케이션들(340A(M-P), 340B(Q-S))을 현재 포함하는 것으로 가정한다.

이전 단락에서 간단히 언급한 것과 같이, 다운로드 디렉토리들(A-B)은 각각 애플리케이션들(340A, 340B)에 더하여 헤드 유닛 프론트엔드 설정들(A-B)을 포함한다. 설정들(A-B)은 웹 코드 렌더러(399)와 호환되는 HTML 코드 또는 다른 웹 코드로 저장될 수 있다. 헤드 유닛(321)에 다운로드되는 헤드 유닛 프론트엔드 설정들(A-B) 중 하나에 따라, 헤드 유닛(321)의 디스플레이(380)는 다른 그래픽 사용자 인터페이스를 디스플레이한다. 디스플레이(380) 및 렌더러(399)를 사용하여 디스플레이되면, 다른 웹 코드 파일들(369A, 369B) 각각은 다른 그래픽 사용자 인터페이스를 생성한다. 예를 들어, 각 그래픽 사용자 인터페이스는 사용자로부터 선택된 특정 바탕화면(wallpaper)과 같은 그 자체의 사용자 맞춤 설정들(user customized settings)을 포함할 수 있다. 다른 헤드 유닛 프론트엔드 설정들(A-B)을 생성하기 위한 방식은 도 9를 참고하여 뒤에서 상세하게 설명된다.

블록(805)에서, 소프트웨어(332)는 신호를 생성하고 전송하여, 휴대폰(320)상의 IP 게이트웨이 소프트웨어가 도 4에서 기술한 방법과 유사하게 헤드 유닛(321)에 애플리케이션들을 전달하기 위한 IP 게이트웨이로 동작하도록 한다. 일 예에서, 도 4와 유사하게, 그러한 신호는 휴대폰(320)에 소프트웨어(331)를 동적으로 로드하고, 소프트웨어(331)가 차량에의 다운로드를 위해 휴대폰상에서 동작하도록 하는 통신들을 포함한다. 휴대폰(320)에 소프트웨어(331)가 이미 로드되고, IP 게이트웨이 동작이 준비되면, 이 신호는 발생되지 않을 수 있다. 다른 예들에서, 신호(345)는 연결(540)이 설정된 이후, 헤드 유닛(321)상의 제어 소프트웨어(330)로부터 유래할 수도 있다.

블록(806)에서, 소프트웨어(332)는 IP 패킷들(545)을 생성하고 전송하여, 디렉토리들 중 선택된 하나로부터 데이터를 차량으로 다운로드하는데, 예를 들어, 애플리케이션들(M-P) 및 설정(A) 또는 애플리케이션들(Q-S) 및 설정(B) 중 하나일 수 있다. IP 패킷들(545)은 휴대폰(320)에 의해 수신되고, 소프트웨어(331)의 동작에 의해 헤드 유닛(321)으로 전달된다. 이 특정 도시에서 IP 패킷들(545)은 그래픽 사용자 인터페이스를 위한 애플리케이션들 및 설정 둘 다를 포함하나, 다른 시나리오들에서는, IP 패킷들(545)은 애플리케이션 또는 설정 중 하나를 포함할 수 있음이 이해되어야 한다. 또한, 선택된 다운로드 디렉토리 내 현재 어떤 애플리케이션도 존재하지 않고, 이전 다운로드로 인해 다운로드 디렉토리 내 저장된 설정들에 변화가 없다면, IP 패킷들(545)은 전송되지 않을 수 있음이 명백하다.

블록(807)에서, 소프트웨어(330)는 IP 패킷들(545)을 수신하고, 거기에 포함된 애플리케이션들을 차량상에 인스톨한다(인스톨은 헤드 유닛(321)의 요소들상 또는 다른 차량 요소들상일 수 있음). 또한 소프트웨어(330)는 웹 코드 렌더러(399)를 사용하여 IP 패킷들(545)로부터 설정을 처리하여, 검출된 전화 번호를 기반으로 특정 그래픽 사용자 인터페이스를 생성한다.

그 후에, 디스플레이(380)를 통해 출력되는 그래픽 사용자 인터페이스는 선택된 다운로드 디렉토리에 저장된 설정들(A-B) 중 하나에 대응된다. 차량의 사용자는 인터페이스로 헤드 유닛(321)을 사용하여 인스톨된 애플리케이션들(M-P 또는 Q-S)을 조작할 수 있다.

소프트웨어(330, 332)는 도 1-3에 기술된 원리들 중 임의의 원리에 따라 동작할 수 있음이 이해되어야 한다. 예를 들어, 소프트웨어(330, 332)는 현재 차량 상태에 따라 활성화된 애플리케이션(들)에 의한 헤드 유닛(321)의 I/O 자원들의 이용을 조절할 수 있다. 다른 예로서, 애플리케이션들이 차량 및 휴대 장치 모두에 인스톨되는 시스템들에서, 소프트웨어(330, 332)는 테이블(도 1의 13)과 유사한 애플리케이션 랭킹/우선권 테이블 내의 차량 인터페이스를 이용하는 모든 애플리케이션들을 포함할 수 있다.

위에서 기술된 예에서, 제어 소프트웨어(330)는 다른 휴대폰들로부터 휴대폰(320)을 고유하게 식별하기 위해 휴대폰(320)의 전화 번호에 접속한다. 다른 예들에서, 헤드 유닛(321)상의 제어 소프트웨어는 다른 휴대폰들로부터 상기 휴대폰을 고유하게 식별하기 위해 통신에 관하여 연결된 휴대폰상에서 다른 값(value)에 접속할 수 있다. 값들의 다른 예들은 휴대폰의 물리 주소(physical address)를 포함할 수 있으나, 이에 제한되는 것은 아니다. 그러한 다른 예들에서, 그러한 값들은 맵핑에서 사용됨이 명백하고, 예를 들어, 다른 값들이 물리 주소들이면 맵핑은 다운로드 디렉토리들과 연관성이 있는 물리 주소들을 포함한다.

위에서 기술된 예에서, 제어 소프트웨어(330)는 접속된 고유 식별자(unique identifier)(이 예에서는 전화 번호)를 서버(322)에 전송한다. 다른 예들에서, 맵핑(350)은 차량상에 저장될 수 있다. 그러한 경우에, 제어 소프트웨어(330)는 비교에 따라 맵핑에 리스트된 특정 다운로드 디렉토리를 식별하고, 특정 다운로드를 명시하는 식별자를 서버(322)에 전송한다. 다음, 서버(322)는 식별된 다운로드 디렉토리로부터 데이터를 전송하는 IP 패킷들(545)로 응답할 수 있다.

서버(322)가 다운로드되기 위해 대기하는 애플리케이션들의 복수의 다운로드 디렉토리들(339A-B)을 포함하는 것은 이미 설명되었다. 도 9는 다운로드 디렉토리들(339A-B)의 생성(creating) 및 디렉토리 단위마다(per-directory basis) 애플리케이션들의 선택과 연관될 수 있는 사용자 웹 포털(905)을 나타내고, 그 웹 포털(905)의 사용예를 표현한다.

차량 사용자는 사용자 웹 포털(905)의 프로필 생성 부분(profile creation portion)(930)을 사용하여 차량에 대응하는 복수의 프로필들(profiles)을 생성할 수 있다. 프로필은 차량을 사용할 수 있는 각 개인에 대해 생성될 수 있다. 필드(field)(927)는 각 개인에 개별적으로 대응하는 휴대폰의 고유 전화 번호 또는 다른 고유 식별자를 요청한다. 각 개인의 이름 또는 각 개인에 대한 다른 정보는 전화 번호(들)과 함께 수집될 수 있다. 프로필 생성 동안 또는 그 후, 서버(322)는 각 프로필을 위한 다운로드 디렉토리를 생성하고, 각 번호/디렉토리 조합(number/directory combination)을 위한 맵핑(350)을 업데이트한다. 일부 예들에서, 부분(930)은 사용자가 생성된 프로필들을 랭크 가능하도록 구성될 수 있어, 헤드 유닛이 하나 이상의 휴대 장치들과 동시에 결합될 수 있다면(이것이 가능한지 여부는 연결 프로토콜에 종속될 수 있음), 대응되는 프로필들 중 상위 랭크된 하나(higher ranked one)가 사용된다.

프로필 생성 동안 또는 그 후, 웹 포털(905)은 컴퓨터 터미널(926)(예를 들어 휴대 장치 또는 데스크톱 컴퓨터와 같은 임의의 인터넷 접속 가능한 컴퓨터 장치)을 사용하여 다운로드 디렉토리들(339A-B)에 포함되게 애플리케이션들을 선택하도록 운용될 수 있다. 컴퓨터 터미널(926)은 (일 예에서 제공자에 의해 운용되는 웹 서버에 의해 관리되는) 사용자 웹 포털(905)의 애플리케이션 선택 부분(928)에 접속하여, 차량상에 인스톨될 수 있는 제어 리스트를 보여준다. 다음, 사용자는 통신들(961)을 전송하여, 디렉토리 단위마다 제어 리스트로부터 사용자가 그의 차량상에 인스톨하고자 하는 애플리케이션들을 선택한다. 이 선택들(962)은 디렉토리 단위마다 다운로드 디렉토리들(339A-B)로 각각 공급된다.

사용자 웹 포털(905)은 또한 사용자가 다운로드 디렉토리들(339A-B)로부터 특정 애플리케이션들을 삭제할 수 있도록 구성될 수 있다. 예를 들어, 사용자는 디렉토리 단위마다 제공자를 통해 다운로드 디렉토리(339A 또는 339B)에 추가된 제공자 선택 애플리케이션들(952) 중 하나를 삭제하고 싶을 수 있다. 삭제는 이미 다운로드 디렉토리(339A 또는 339B)에 전송된 애플리케이션의 삭제를 통해서나, 다운로드 디렉토리(339A 또는 339B)에 이러한 애플리케이션이 추가되기 전에 원치 않는 특정 애플리케이션을 지시함으로써 이루어질 수 있다.

사용자 웹 포털(905)은 또한 헤드 유닛 프론트엔드 설정 맞춤 부분(head unit frontend configuration customization portion)(928)을 포함할 수 있다. 이 부분(928)은 개인들의 요청들에 따라 맞춤화된 각 개인의 설정과 함께 새로운 설정들(369A-B)이 다운로드 디렉토리들(339A-B)에 추가될 수 있게 한다. 예를 들어, 제1 바탕화면 배경(background)은 다운로드 디렉토리(339A)에 추가될 수 있고, 다른 제2 바탕화면 배경은 다운로드 디렉토리(339B)에 추가될 수 있다. 다른 맞춤들(customizations)은 맞춤화된(customized) 그래픽 인터페이스 버튼들, 맞춤화된 그래픽 사용자 인터페이스 레이아웃(layout), 구입 이미지들(custom images) 등을 포함할 수 있다.

위에 따르면, 애플리케이션들은 차량당(per-vehicle) 디렉토리 단위마다 다운로드 디렉토리(339A-B)에 축적될 수 있다. 휴대 장치들 중 특정한 하나에 연결된 헤드 유닛에 따라, 다운로드 디렉토리들(339A-B) 중 대응되는 하나로부터 데이터가 다운로드될 수 있고, 차량상에 인스톨될 수 있어, 맞춤화된 애플리케이션 집합(customized application set) 및 맞춤화된 사용자 인터페이스를 공급한다.

웹 포털(905)의 인터페이스와 유사한 인터페이스가 차량의 헤드 유닛상에 디스플레이될 수 있음이 이해되어야 한다. 다음, 사용자는 제어 리스트로부터 애플리케이션들을 선택하기 위해 그러한 인터페이스로부터 선택들을 할 수 있다. 인터페이스로부터 선택들이 이루어지면, 선택된 애플리케이션들은 다운로드 디렉토리에 들어가는 대신 즉시 차량에 다운로드될 수 있다.

도 10은 헤드 유닛의 설정에 따라 헤드 유닛 그래픽 인터페이스를 선택하는 시스템을 나타낸다.

시스템(1000)은 이전에 기술된 서버들 및 헤드 유닛들 중 임의의 것과 유사한 요소들을 포함할 수 있는 서버(1022) 및 헤드 유닛(1021)을 포함한다. 서버(1022) 및 헤드 유닛(1021)은 헤드 유닛(1021)에 연결된 휴대 장치(미도시)를 사용하여 통신하는 것이 이해되어야 한다. 헤드 유닛(1021)은 제어 소프트웨어(1030)를 포함하고, 서버(1022)는 제어 소프트웨어(1032)를 포함한다.

소프트웨어(1032)는 헤드 유닛(1021)의 설정을 식별하는데, 예를 들어, 정보를 수집하기 위해 헤드 유닛(1021)을 탐색(probing)(1081)함으로써 식별한다. 소프트웨어(1030)는 헤드 유닛(1021)의 설정을 식별하는 정보로 응답(1082)한다. 응답(1082)은 다음 중 적어도 하나를 포함할 수 있다: 차량의 제품/모델/햇수(make/model/year), 미리 정의된 코드(predefined code), 또는 헤드 유닛(1021)의 설정(예를 들어, 컬러/흑백 디스플레이, 기본 해상도(native resolution) 등)의 애드 혹 리스트(ad hoc listing).

다음, 소프트웨어(1032)는 헤드 유닛 정보(1082)를 기반으로 복수의 그래픽 사용자 인터페이스들로부터 선택한다. 예를 들어, 헤드 유닛 정보(1082)가 미리 정의된 코드를 포함하면, 소프트웨어(1032)는 코드를 그래픽 사용자 인터페이스들(Y-Z)에 대한 코드들의 저장된 맵핑(1085)과 비교할 수 있다. 선택된 그래픽 사용자 인터페이스는 정보(1082)에 의해 보고된 것과 같은 헤드 유닛(1021)의 특정 설정에 대응된다. 예를 들어, 헤드 유닛(1021)이 흑백 디스플레이를 포함하면, 선택된 그래픽 사용자 인터페이스(Graphical User Interface, GUI)는 인터페이스 Y일 수 있고, 헤드 유닛(1021)이 컬러 디스플레이를 포함하면, 선택된 GUI는 인터페이스 Z일 수 있다. 또는, 헤드 유닛(1021)이 제1 값의 기본 해상도를 포함하면, 선택된 GUI는 인터페이스 Y일 수 있고, 헤드 유닛(1021)이 제2 값의 기본 해상도를 포함하면, 선택된 GUI는 인터페이스 Z일 수 있다. 자동차의 제품/모델/햇수가 제1 디자인의 인테리어(interior)(소위 화려한 모티브(luxury motif))를 지시하면, 선택된 GUI는 인터페이스 Y일 수 있고, 자동차의 제품/모델/햇수가 제2 디자인의 인테리어(소위 스포티 모티브(sporty motif))를 지시하면, 선택된 GUI는 인터페이스 Z일 수 있다.

그래픽 사용자 인터페이스가 선택되면, 소프트웨어(1032)는 그래픽 사용자 인터페이스(Y-Z) 중 선택된 하나의 IP 패킷 이동(trasfer)(1045)을 수행한다. IP 패킷 이동(1045)은 휴대폰(미도시)의 이전에 기술된 IP 게이트웨이 소프트웨어를 이용할 수 있음이 이해되어야 한다. 소프트웨어(1030)는 수신된 그래픽 사용자 인터페이스를 자동적으로 인스톨한다. 선택된 그래픽 사용자 인터페이스는 디폴트(default) 그래픽 사용자 인터페이스(1090) 또는 이동(1045) 이전에 헤드 유닛(1021)상에 탑재된 이전에 다운로드된 그래픽 사용자 인터페이스를 대체할 수 있다.

이전에 기술된 프론트엔드 설정들은 선택되고 인스톨된 GUI에 적용될 수 있음이 이해되어야 한다. 예를 들어, 선택된 GUI는 헤드 유닛(1021)상에 인스톨될 수 있고, 다음, 헤드 유닛(1021)에 현재 연결된 휴대 장치의 전화 번호에 따라 맞춤화된 프론트엔드 선택을 기반으로 외관상(in appearance) 더 수정될 수 있다.

도 11은 원격 컴퓨터 승인들(approvals)을 생성하고 헤드 유닛에 전송하는 시스템을 나타낸다.

시스템(1100)은 이전에 기술된 서버들 및 헤드 유닛들 중 임의의 것과 유사한 요소들을 포함할 수 있는 서버(1122) 및 헤드 유닛(1121)을 포함한다. 서버(1122) 및 헤드 유닛(1121)은 휴대 장치(1131)를 사용하여 통신하는 것이 이해되어야 한다. 헤드 유닛(1121)은 제어 소프트웨어(1130)를 포함하고, 서버(1122)는 제어 소프트웨어(1132)를 포함한다.

헤드 유닛(1121)은 가상 네트워크 컴퓨터(Virtual Network Computing (VNC

)) 클라이언트(1148)와 같은 휴대 장치(1131)상에서 작동하는 VNC 서버(1149)에 연결하기 위한 프로그램을 보여주는 원격 데스크톱(remote desktop)을 포함한다. 배경 방법에 의해, VNC 클라이언트 및 서버는 통신하여, 서버의 데스크톱 또는 클라이언트의 디스플레이상의 다른 현재 화면(current view)을 디스플레이한다. 다음, 클라이언트에 직접 연결된 휴먼 인터페이스 장치(들)(예를 들어, 키보드, 마우스 등)은 VNC 서버를 운영하는 컴퓨터 장치를 원격으로 제어하기 위해 디스플레이된 이미지와 결합되어 사용될 수 있다. 애플리케이션이 VNC 서버를 포함하는 컴퓨터 장치상에서 전체 화면(full screen) 모드로 작동되면, 다음, VNC 서버를 포함하는 컴퓨터 장치는 (전체 데스크톱보다는) 그 애플리케이션을 제어한다.

제어 소프트웨어(1130)는 휴대 장치(1131)로부터 특정 애플리케이션 X(1140)을 명시하는 요청(1155)을 수신한다. 제어 소프트웨어(1130)는 요청(1155)에 대응하는 애플리케이션 식별자를 식별하는데, 요청(1155)으로부터 식별자 자체를 추출함으로써 식별하거나, 요청으로부터 또는 휴대 장치(1131)와의 임의의 통신으로부터 얻은 정보를 기반으로 룩업(lookup)을 사용함으로써 식별한다. 제어 소프트웨어(1130)는 애플리케이션 식별자를 포함하는 통신(1156)을 전송한다.

제어 소프트웨어(1132)는 애플리케이션 식별자를 내부 테이블(internal table)과 비교하고, 애플리케이션 X에 대한 VNC 승인(1157)을 생성한다. VNC 승인(1157)은 VNC가 이 애플리케이션 X에 대해 승인되는 특정 상태들을 명시한다. 예를 들어, 애플리케이션 X가 내비게이션 애플리케이션이면, 승인(1157)은 차량이 정지하거나 이동하면 VNC가 승인됨을 명시할 수 있다. 그에 반해, 애플리케이션 X가 미디어 생성 애플리케이션(media creation application)이면, 승인(1157)은 차량이 정지하는 경우에만 VNC가 승인됨을 명시할 수 있다.

또한 VNC 승인(1157)은 애플리케이션이 현재 전체 화면 모드 또는 윈도우 모드(windowed mode)로 작동하는지 여부를 기반으로 다른 승인들을 명시할 수 있다. 예를 들어, 내비게이션 애플리케이션은 차량이 이동하나 오직 내비게이션 애플리케이션이 휴대 장치(1131)상에서 전체 화면 모드로 작동하는 동안에만 승인될 수 있다. 차량이 이동하는 동안 사용자가 내비게이션 애플리케이션을 윈도우 모드로 전환하면, VNC 기능(functionality)이 즉시 방지된다.

VNC 승인(1157)은 또한 전화 번호들을 명시할 수 있다. 예를 들어, 휴대 장치(1131)가 미디어 플레이어 애플리케이션(media player application)을 작동하나, 휴대 장치가 특정 전화 번호를 포함하는 경우에만(이는 부모 제어(parental control)의 형태로 사용될 수 있음), VNC가 허용될 수 있다.

제어 소프트웨어(1130)는 수신된 VNC 승인(1157)을 VNC 승인들의 데이터베이스(1135) 내에 저장한다. 제어 소프트웨어(1130)는 데이터베이스(1135)에 저장된 VNC 승인들을 기반으로 상태들을 지속적으로(continuously) 모니터하여, 제어 신호(1160)를 생성한다. 제어 신호(1160)는 휴대 장치(1131)의 화면(view)(1161)이 VNC 클라이언트(1148)에 의해 헤드 유닛(1121)의 디스플레이에 현재 디스플레이될 수 있는지 여부를 제어한다. 제어 신호(1160)는 또한 헤드 유닛(1121)의 입력 인터페이스를 사용하여 만들어진 입력들이 VNC 서버(1149)로 전송(1162)되는지 여부를 제어한다.

도 12는 새로운 애플리케이션 또는 새로운 애플리케이션을 선택하는 사용자 웹 포털을 위한 요청을 생성하는 휴대 장치에 응답하여, 그래픽 사용자 인터페이스 업데이트들을 헤드 유닛에 밀어 넣는(push) 시스템을 나타낸다.

시스템(1200)은 이전에 기술된 서버들 및 헤드 유닛들 중 임의의 것과 유사한 요소들을 포함할 수 있는 서버(1222) 및 헤드 유닛(1221)을 포함한다. 서버(1222) 및 헤드 유닛(1221)은 휴대 장치(1231)를 사용하여 통신하는 것이 이해되어야 한다.

서버(1222)는 적어도 두 가지 다른 형태로 시스템(1200)에서 사용될 새로운 애플리케이션의 지시를 수신할 수 있다(새로운 애플리케이션이란 용어는 이전에 헤드 유닛(1121) 및/또는 확장 인터페이스로 이용되는 헤드 유닛(1121)에 다운로드되지 않은 애플리케이션을 지시함). 일 형태에서, 휴대 장치(1231)는 새로운 애플리케이션 X(1240)의 지시를 전송하여, 헤드 유닛(1221)을 확장 인터페이스로 이용한다. 좀 더 구체적으로, 이 지시는 휴대 장치(1231)로부터 수신된 요청(1270)에 응답하여 제어 소프트웨어(1230)에 의해 생성되고 전송되는 승인 요청(approval request)(1271)이다.

서버(1222)가 새로운 애플리케이션의 지시를 수신할 수 있는 다른 방법은, 사용자 웹 포털(1205)을 통한 제어로부터이다. 사용자 웹 포털(1205)은 이전에 기술된 웹 포털들과 유사하다. 애플리케이션 선택 툴(tool)(1228)을 사용하여, 사용자는 헤드 유닛상에 인스톨을 위한 대응하는 다운로드 디렉토리(미도시)에 포함되는 애플리케이션들을 선택하기 위해 임의의 원격 컴퓨터를 사용할 수 있다. 따라서, 새로운 애플리케이션을 포함하는 수신된 선택(1274)은 시스템(1200)에서 사용될 새로운 애플리케이션의 지시의 다른 형태이다.

그러한 지시의 검출에 응답하여, 제어 소프트웨어(1232)는 새로운 애플리케이션 X를 위한 그래픽 사용자 인터페이스 업데이트를 포함하는 IP 패킷 이동(1245)의 전송 여부를 결정한다. 새로운 애플리케이션 X가 이전에 기술된 애플리케이션들의 제어 리스트(도 6)에 포함되지 않으면, 그러한 IP 패킷 이동이 전송되지 않음이 명백하다. 일 예에서, 그래픽 사용자 인터페이스 업데이트는 이전에 선택되고 인스톨된 그래픽 사용자 인터페이스(도 10)를 수정하여, 새로운 애플리케이션 X에 접속하기 위한 아이콘(icon)을 추가한다. 다른 예에서, 그래픽 사용자 인터페이스 업데이트는 새로운 애플리케이션 X의 동작을 위해 이전에 선택되고 인스톨된 그래픽 사용자 인터페이스에 대한 업데이트의 임의의 다른 형태를 포함한다. 제어 소프트웨어(1230)는 요청(1270)의 전송 및/또는 선택들(1274)에 응답하여 업데이트를 자동적으로 인스톨한다. 다운로드가 다운로드 디렉토리에서 차량 파워 업을 대기하고 있는 경우에, 이동(1245)은 애플리케이션 자체의 다운로드와 함께 포함될 수 있음이 명백하다.

도 13a는 부모 제어 방식(parental control scheme)의 이전 동작(pre-operation)을 도시한 흐름도를 나타낸다.

블록(1301)에서, 서버는 적어도 하나의 프로필을 부모 제어에 종속된 것으로 지정한다. 이 프로필은 계정 유보(account holding)에 의해 선택될 수 있는데, 예를 들어, 웹 포털을 사용하여 선택을 표시(marking)함으로써 선택될 수 있다.

블록(1302)에서, 서버는 부모 제어에 종속된 프로필에 대해 부모(parent)(일반적으로 계정 유보자(account holder))로 지정된 사용자를 위한 로그인(login)을 수신한다. 블록(1303)에서, 서버는 부모 제어에 종속된 프로필과 연관된 애플리케이션들의 리스트가 웹 포털을 사용하여 디스플레이되도록 한다.

블록(1304)에서, 리스트를 디스플레이한 후, 서버는 디스플레이된 리스트로부터 선택들을 수신한다. 서버는 이 선택들을 부모 제어에 종속된 프로필에 저장할 수 있다. 조건부 승인(conditional approval)의 경우에(조건부 승인은 이후에 더 상세히 기술됨), 선택들은 리스트 및/또는 더 상세한 정보로부터 애플리케이션들을 포함할 수 있다.

도 13b는 부모 제어 방식의 동작을 도시한 흐름도를 나타낸다.

블록(1320)에서, 헤드 유닛과 통신에 관하여 연결된 휴대폰에 응답하여, 헤드 유닛은 서버와 통신을 위해 사용되는 휴대폰의 전화 번호를 획득한다. 블록(1321)에서, 헤드 유닛이 분석을 위해 서버로 전화 번호를 전송한다. 획득된 전화 번호가 부모 제어에 종속된 것으로 지정된 프로필과 매치하지 않으면, 다음, 블록(1322)에서 부모 제어 프로세스가 완료된다.

이와 달리, 획득된 전화 번호가 부모 제어에 종속된 프로필에 대응하면, 다음, 블록(1323)에서 서버는 부모 제어를 실행한다. 일 예에서, 그러한 실행은 VNC 승인 프로세스(approval process)와 유사하고, 다음 단락에서 기술되는 블록들(1323-1327)을 포함한다.

블록(1323)에서, 서버는 부모 제어 메시지를 헤드 유닛에 전송한다. 블록(1324)에서, 헤드 유닛은 부모 제어 메시지를 기반으로 상태들을 지속적으로(continuously) 모니터한다. 블록(1325)에서, 헤드 유닛은 특정 애플리케이션이 확장 인터페이스로 헤드 유닛을 이용하는 것 및/또는 헤드 유닛상에 인스톨된 특정 애플리케이션이 작동하는 것을 차단한다. 예를 들어, 헤드 유닛은 특정 휴대폰이 전화 통화(telephone call)를 수신한다는 지시를 수신할 수 있으나, 전화 통화를 위한 확장 인터페이스로 헤드 유닛의 사용은 차단할 수 있다. 또는, 다른 예에서 헤드 유닛은 헤드 유닛상에서 미디어 플레이어 애플리케이션을 작동하려는 시도를 차단할 수 있다. 지속적인 모니터링은 수신된 부모 제어 메시지들을 저장한 헤드 유닛 상의 데이터베이스에 의해 가능해질 수 있다.

블록(1326)에서, 헤드 유닛은 특정 애플리케이션이 확장 인터페이스로 헤드 유닛을 이용하는 것 및/또는 헤드 유닛상에서 직접 작동하는 것을 조건부로 차단한다. 예를 들어, 헤드 유닛은 특정 휴대폰이 전화 통화를 수신한다는 지시를 수신할 수 있으나, 착신 콜(incoming call)상의 콜러 ID 필드(caller ID field)의 값을 기반으로 확장 인터페이스로 헤드 유닛의 사용을 조건부로 차단할 수 있다. 좀 더 구체적으로, 부모 제어 메시지는 헤드 유닛이 폰을 위한 확장 인터페이스를 제공하는 것을 방지하기 위해 특정 전화 번호들을 예외들로 지정할 수 있다. 헤드 유닛은 휴대폰으로부터 콜러 ID 값을 획득하고, 휴대폰이 헤드 유닛의 인터페이스를 이용하는 것을 조건부 차단한다. 다른 예에서, 헤드 유닛은 차량의 상태(condition)를 기반으로 애플리케이션을 조건부 차단할 수 있는데, 예를 들어, 차량이 현재 이동 중이면, 헤드 유닛은 휴대폰이 헤드 유닛의 인터페이스를 이용하는 것을 차단한다.

블록(1327)에서, 애플리케이션이 부모 제어 메시지에 따라 허용되면, 헤드 유닛은 특정 애플리케이션을 차단하지 않는다. 이 경우에, 헤드 유닛은 애플리케이션이 서버에 의한 승인에 따라(예를 들어, 애플리케이션이 제어 리스트(도 6)상에 있는지 여부에 따라) 작동하도록 할 수 있다.

다른 예들에서, 시스템은 위에서 구체적으로 기술된 프로세스들과 다른 프로세스들을 사용하여 부모 제어 방식을 실행할 수 있음이 명백하다. 예를 들어, 다른 예에서, 블록들(1323-1327)의 프로세스들은 사용되지 않는다. 대신에, 헤드 유닛은 지속적으로 상태들 및 애플리케이션 요청들을 서버에 보고하고, 서버는 부모 제어 설정들에 따라 현재 승인을 동적으로 철회한다. 다음, 서버는 헤드 유닛을 제어하여, 현재 비승인된 애플리케이션을 차단한다.

본 기술분야에서 통상의 지식을 가진 자라면 본 발명의 원리들로부터 벗어나지 않는 범위 내에서 위에서 기술된 실시예들의 상세 사항들에 많은 변형을 가할 수 있음이 자명하다. 따라서, 본 발명의 범위는 오직 하기의 특허청구범위로부터 결정되어야 한다.

상기에서 기술된 대부분의 장비(equipment)는 하드웨어 및 연관된(associated) 소프트웨어를 포함한다. 예를 들어, 일반적인 내비게이션 장치는 기술된 동작들을 수행하기 위해 하나 이상의 프로세서들 및 그 프로세스들상에서 실행될 수 있는 소프트웨어를 포함할 수 있다. 여기서 소프트웨어란 용어는 보통 이해되는 의미로 사용되며, 기계 또는 프로세서에 의해 사용될 수 있는 데이터뿐 아니라 프로그램들 또는 루틴들(routines)(서브루틴들, 오브젝트들, 플러그인들(plug-ins) 등)을 나타낸다. 잘 알려진 바와 같이, 컴퓨터 프로그램들은 일반적으로 기계-판독 가능 (machine-readable) 또는 컴퓨터 판독 가능 저장 매체 내에 저장된 명령들을 포함한다. 본 발명의 일부 실시예들은 디지털 메모리와 같은 기계-판독 가능 또는 컴퓨터-판독 가능 저장 매체 내에 저장된 실행 가능한 프로그램들 또는 명령들을 포함할 수 있다. 임의의 특정 실시예에서 종래의 의미의 "컴퓨터"가 필요함을 의미하지 않는다. 예를 들어, 임베디드되거나 다른 다양한 프로세서들이 여기서 기술된 요소들과 같은 장비 내에 사용될 수 있다.

다시, 소프트웨어 저장을 위한 메모리는 잘 알려져 있다. 일부 실시예들에서, 주어진 프로세서와 연관된 메모리는 프로세서와 동일한 물리적 장치("온-보드(on-board)" 메모리) 내에 저장될 수 있다; 예를 들어, 집적회로 마이크로프로세서 등의 내부에 배치된 RAM 또는 플래시(FLASH) 메모리. 다른 예들에서, 메모리는 외부 디스크 드라이브, 저장 어레이(storage array) 또는 이동용(portable) 플래시 전자 열쇠(FLASH key fob)와 같은 독립 장치를 포함한다.

그러한 경우들에서, 메모리와 디지털 프로세서가 함께 기능적으로 연결되거나, 예를 들어 I/O 포트(port), 네트워크 연결 등을 통해 서로 통신하면, 메모리는 디지털 프로세서와 "연관(associated)"되어, 프로세서는 메모리에 저장된 파일을 독출할 수 있다. 연관된 메모리는 디자인 (ROM) 또는 승인 설정들의 장점(virtue)에 의해 "독출만(read only)" 되거나 아닐 수도 있다. 다른 예들은 WORM, EPROM, EEPROM, 플래시 등을 포함하나, 이에 제한되는 것은 아니다. 이 기술들은 종종 솔리드 스테이트(solid state) 반도체 장치로 구현된다. 다른 메모리들은 종래 회전 디스크 드라이브와 같이 이동 파트들을 포함할 수 있다. 그러한 모든 메모리들은 "기계 판독 가능" 또는 "컴퓨터-판독 가능"하고, 여기서 기술된 기능들을 구현하기 위한 실행 가능한 명령들을 저장하기 위해 사용될 수 있다.

"소프트웨어 제품(software product)"은 일련의 실행 가능한 명령들이 기계-판독 가능 형태로 저장된 메모리 장치를 나타내고, 소프트웨어 제품에 적절하게 접속하는 적합한 기계 또는 프로세서는 명령들을 실행하고, 명령들에 의해 구현되는 프로세스를 수행한다. 소프트웨어 제품들은 종종 소프트웨어를 분배하기 위해 사용된다. 위에서 요약된 제한을 포함하지 않는 기계-판독 가능 메모리의 임의의 유형은 소프트웨어 제품을 제조하기 위해 사용될 수 있다. 그렇긴 하지만, 소프트웨어가 전자 전송("다운로드")를 통해 분배될 수 있음이 또한 알려져 있고, 그러한 경우 전송의 전송단(trasmitting end) 또는 수신단(receiving end), 또는 둘 다에서 대응되는 소프트웨어 제품이 일반적으로 존재한다.

본 발명의 최선의 실시예로 본 발명의 원리들이 기술되고, 설명되었고, 본 발명은 그러한 원리들로부터 벗어나지 않는 범위에서 배치 및 상세 사항이 수정될 수 있음이 명백하다. 다음 특허청구범위의 사상 및 범위 내에서 모든 수정 및 변형을 청구한다.

Claims

자동차에서 실행 가능한 사용자 애플리케이션 프로그램들을 원격으로 관리하기 위한 컴퓨터-실행(computer-implemented) 방법에 있어서, 상기 방법은:
이용 가능한 사용자 애플리케이션 프로그램들의 리스트를 유지하는 단계;
명시된(specified) 자동차 제품(make) 및 모델에서 사용하기 위해 상기 이용 가능한 사용자 애플리케이션 프로그램들 중 적어도 하나를 승인하되, 상기 승인은 상기 자동차 OEM 또는 서비스 제공자들에 의하거나 대신에 의해 결정되는 단계;
상기 승인된 애플리케이션들을 식별하는 애플리케이션들의 제어 리스트를 형성하는 단계;
특정 자동차에 다운로드하기 위해 승인된 애플리케이션들의 상기 제어 리스트로부터 적어도 하나의 애플리케이션을 선택하되, 상기 선택은 상기 특정 자동차의 소유자에 의하거나 대신에 의해 이루어지는 단계;
상기 선택된 애플리케이션 프로그램을 상기 특정 자동차에 무선으로 다운로드하는 단계; 및
상기 특정 자동차의 헤드 유닛상에 작동을 위해 상기 다운로드된 애플리케이션 프로그램을 인스톨하는 단계를 포함하는 방법.
제1항에 있어서,
상기 무선으로 다운로드하는 단계는, 상기 자동차로부터의 제어 신호에 응답하여 서버에서 자동적으로 실행되고, 상기 제어 신호는 상기 자동차의 파워-업(power-up)에 의하거나 상기 자동차 내 사용자 휴대 무선 장치의 인식(recognition)에 응답하여 촉발되는(triggered) 방법.
제1항에 있어서,
상기 애플리케이션을 선택하는 단계는, 사용자 웹 포털상에서 실행되거나 상기 자동차의 상기 헤드 유닛상에서 실행되는 애플리케이션 선택 소프트웨어를 통해 사용자에 의해 수행되는 방법.
제3항에 있어서,
상기 자동차로부터 원격으로 위치되는 서버 컴퓨터를 제공하고, 상기 자동차와 정보를 교환하기 위해 무선 통신들을 접속하는 단계;
상기 서버 내에 복수의 다운로드 디렉토리들을 구현하고, 각 다운로드 디렉토리 내 대응하는 사용자에 의해 선택된 애플리케이션 프로그램들의 대응하는 집합을 저장하는 단계;
상기 자동차로부터 신호를 수신하는 단계 - 상기 신호는 상기 자동차 내에서 검출된 사용자 휴대폰의 전화 번호를 포함함 -; 및
상기 수신된 전화 번호를 상기 서버 내 상기 다운로드 디렉토리들 중 대응하는 하나에 연관시키는 단계를 더 포함하되,
상기 무선으로 다운로드하는 단계는, 상기 대응하는 다운로드 디렉토리로부터 상기 자동차로 애플리케이션 프로그램들의 상기 선택된 집합을 다운로드하는 단계를 포함하는 방법.
제4항에 있어서,
적어도 하나의 다운로드 디렉토리 내 대응하는 헤드 유닛 프론트엔드 설정을 저장하는 단계를 더 포함하되,
상기 무선으로 다운로드하는 단계는, 상기 자동차 헤드 유닛의 사용자 인터페이스를 수정하기 위해 상기 대응하는 다운로드 디렉토리로부터 상기 자동차로 상기 헤드 유닛 프론트엔드 설정을 다운로드하는 단계를 포함하는 방법.
제4항에 있어서,
상기 사용자 휴대폰이 IP 게이트웨이를 제공하도록 구성하는 단계를 더 포함하되,
상기 무선으로 다운로드하는 단계는, 상기 휴대폰 IP 게이트웨이를 통해 상기 대응하는 다운로드 디렉토리로부터 상기 자동차로 애플리케이션 프로그램들의 상기 선택된 집합을 다운로드하는 단계를 포함하는 방법.
제6항에 있어서,
상기 사용자 휴대폰이 IP 게이트웨이를 제공하도록 구성하는 상기 단계는, 상기 서버로부터 상기 휴대폰으로 IP 게이트웨이 소프트웨어를 다운로드하는 단계를 포함하는 방법.
제6항에 있어서,
상기 무선으로 다운로드하는 단계는, 상기 휴대폰 IP 게이트웨이를 통해 상기 대응하는 다운로드 디렉토리로부터 상기 자동차로 상기 헤드 유닛 프론트엔드 설정을 다운로드하는 단계를 포함하는 방법.
제4항에 있어서,
상기 자동차로부터의 상기 신호는 상기 헤드 유닛으로부터 상기 휴대폰으로 로컬 연결을 통해 전송되고, 무선 통신 네트워크를 통해 상기 서버로 상기 휴대폰에 의해 중계되는 방법.