KR101075388B1

KR101075388B1 - 복수의 네트워크 주변장치 드라이버들의 컴포넌트들을 유지보수하기 위한 방법, 시스템, 및 컴퓨터 판독가능 기록 매체

Info

Publication number: KR101075388B1
Application number: KR1020040021479A
Authority: KR
Inventors: 로버트이. 올레드; 에밀지. 안토노브; 미카엘피. 호랄; 티모씨제이. 리틀; 탈리 로쓰; 알버트엘. 팅
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-03-31
Filing date: 2004-03-30
Publication date: 2011-10-24
Also published as: CN1322411C; CN1534449A; JP4549715B2; JP2004303252A; US7457831B2; EP1465065A3; US20040215754A1; KR20040086757A; EP1465065A2

Abstract

본 발명에서는 네트워크 주변장치 드라이버 유지보수 프레임워크 및 그에 대응하는 방법이 개시된다. 프레임워크는 일련의 드라이버 버전 기술(driver version descriptions)을 포함하는 드라이버 버전 식별 레벨을 포함한다. 각각의 드라이버 버전 기술은 각각의 특정한 드라이버 버전을 구성하는 일련의 컴포넌트 버전들을 포함한다. 드라이버 버전 식별 레벨의 하위 레벨인 드라이버 컴포넌트 레벨은, 그 드라이버 버전들에 의해 식별된 컴포넌트 버전들을 구성하는 일련의 드라이버 파일들을 포함하는, 고유하게 식별되는 컴포넌트 버전들(컨테이너들)을 포함한다. 또한 본 발명에서는 동시에 활성화된 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 방법이 개시된다. 이 방법은, 기기에 의해 수행되는 이하의 단계들을 포함하는 방법을 통해 새로운 드라이버를 그 기기 상에 저장하는 것을 포함한다. 처음에 기기는 드라이버 컴포넌트의 버전을 구성하는 일련의 드라이버 파일들을 저장하기 위한 컨테이너를 디렉토리 구조 내에 설정한다. 그 새로운 컨테이너에 고유 식별자 명칭(unique identifier name)이 할당된다. 그 컴포넌트 버전과 관련된 일련의 드라이버 파일들이 그 컨테이너 내에 삽입된다.

네트워크 주변장치, 드라이버, 유지보수, 버전, 식별, 클라이언트, 서버.

Description

복수의 네트워크 주변장치 드라이버들의 컴포넌트들을 유지보수하기 위한 방법, 시스템, 및 컴퓨터 판독가능 기록 매체{PERIPHERAL DEVICE DRIVER MAINTENANCE SCHEME FOR NETWORKED PERIPHERAL DEVICE CLIENTS}

도 1은 본 발명의 일 실시예를 수행하기 위한 예시적인 컴퓨터 시스템을 도시하는 블록도.

도 2는 본 발명이 유리하게 편입될 수 있는 대표적인 네트워크 환경을 묘사하는 상위 레벨 개요도.

도 3은 본 발명의 예시적인 네트워크 실시예의 서버들 및 클라이언트들 내부에서 유지보수되는 다양한 드라이버 관련 소프트웨어 및 정보를 도시적으로 나타내는 개요도.

도 4a는 본 발명의 일 실시예의 단일한 드라이버 패키지의 예시적인 컴포넌트들을 나타내는 블록도.

도 4b는 드라이버의 버전들 및 그들이 추출되어 나온 그들의 패키지들을 조직화하고 식별하기 위한 복수의 레벨들을 나타내는 예시적인 계층적 트리 구조도(hierarchical tree diagram).

도 5a는 활성화된 드라이버 디렉토리 내에 설치된 각각의 드라이버에 대응하는 일련의 서브-디렉토리 및 매니페스트(manifest)를 포함하는 예시적인 활성화된 드라이버 디렉토리 조직 구조를 나타내는 도면.

도 5b는 하나의 클라이언트가 동일한 드라이버의 상이한 버전들을 실행하는 두 서버와의 동시 호환성(simultaneous compatibility)을 지원할 수 있는, 예시적인 네트워크 주변장치의 배치를 나타내는 도면.

도 6은 메타데이터 저장소(metadata store)에 대한 예시적인 데이터베이스 스키마를 나타내는 도면.

도 7은 본 발명을 실시하는 클라이언트를 위한 프린트 스풀러(print spooler)에 의해 지원되는 예시적인 일련의 메소드/함수(methods/functions)들을 나타내는 도면.

도 8은 드라이버 패키지 저장소 내에 패키지를 설치하기 위한 일련의 단계들을 요약하는 흐름도.

도 9는 특정 서버에 대한 클라이언트 기기 상에 적합한 드라이버 버전들을 유지보수하기 위한 일련의 단계들을 요약하는 흐름도.

도 10은 서버와 상호 작용하는 과정에서 클라이언트가 드라이버 버전에 접근하는 방법을 요약하는 흐름도.

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

100 : 운영 환경

200 : 컴퓨터 네트워크 환경

202 : 클라이언트 기기들

204, 205 : 프린트 서버들

206, 208 : 네트워크 프린터들

212 : 중앙 드라이버 저장소

300 : 드라이버 패키지 저장소

302 : 활성화된 드라이버 저장소

304 : 메타데이터 저장소

450 : 드라이버 패키지들의 컨테이너

460, 462, 및 464 : 패키지 컨테이너

504 : 매니페스트 정보

본 발명은 일반적으로 네트워크 컴퓨팅 시스템에 관한 것이다. 보다 구체적으로는, 본 발명은 클라이언트 기기들이 주변장치(예를 들어, 프린터, 스캐너, 다기능 주변장치, 기타)를 공유하는 네트워크 환경에서 네트워크 주변장치 클라이언트들을 관리하기 위한 방법 및 컴퓨터 시스템 메커니즘과 관련된 것이다. 네트워크 클라이언트들은 공유되는 주변장치와 통신하기 위해 클라이언트 기기 상의 로컬 영역에서(locally) 로딩되는 드라이버 및 관련된 드라이버 컴포넌트들에 의존한다.

네트워크 상에서 서로 연결된 복수의 개별 사용자/컴퓨터들을 포함하는 조직(enterprise) 내부에서 프린터 및 다른 주변장치들을 이용하기 위한 대중적이고 경제적인 한 가지 방법은 그 복수의 개별 사용자/컴퓨터들 간에 네트워크 주변 장치를 공유하는 것이다. 각각의 클라이언트 기기를 위한 전용 주변장치를 제공하기보다는, 복수의 사용자들이 주변장치를 공유할 수 있도록 네트워크는 네트워크 클라이언트 기기들 및 서버들의 고유한 기기 상호 간 통신 능력을 강화한다. 그러한 공유는 주변장치의 이용 정도를 향상하며 네트워크로 연결된 사용자에게 주변장치 서비스를 제공하는 비용을 절감시킨다.

복수의 네트워크 클라이언트들에 의한 주변장치의 공유는 각각의 클라이언트가 네트워크 상의 여러 종류의 주변장치들(예를 들어 프린터들)에 접근할 수 있는 기회를 제시하고, 클라이언트들은 드라이버들을 통해 다양한 주변장치를 지원하는 서버들과 통신한다. 드라이버들은 주변장치 연결을 위한, 클라이언트와 서버 간의 다양한 태양의 상호 작용(interaction)을 지원한다.

수백 명의 사용자들에 의해 공유되는 복수의 주변장치들을 포함하는 대형 네트워크에서 주변장치 드라이버의 관리는 클라이언트 기기 상의 드라이버들의 검색, 저장, 설치(활성화), 및 업데이트를 포함한다. 그러한 환경에서의 드라이버 관리는, 물리적으로 각각의 클라이언트 기기로 가서 물리적으로 새로운 드라이버들을 로딩하는 관리자(administrator)를 통해서는 쉽게 이루어지지 않는다. 이전의, 공지된 "포인트 앤드 프린트(point-and-print)" 프린터 드라이버 관리 형태(printer driver management arrangement)에서는, 프린터 드라이버들은 소스로부터 타깃 클라이언트 기기로 파일 별로 전송되었다. 그러한 업데이트 메커니즘은 여러 문제를 일으키는데, 이 문제들은 주어진 장치에 대하여 불완전한 소프트웨어 패키지를 설치하거나, 파일이 업데이트되는 동안 특정한 주변장치에 대한 드라이버 파일의 적 합한 버전을 보존하는데 실패하거나, 주변장치 및 클라이언트 상에 로딩된 드라이버들 사이에서 일관성/호환성을 유지하는데 일반적으로 실패하는 것을 포함한다.

주변장치 드라이버 불일치(mismatches)는 주변장치가 클라이언트/서버 네트워크 주변장치 환경에서 이용될 때 문제가 된다. 클라이언트 및 서버는 드라이버의 동일한 버전을 실행할 때 가장 잘 동작한다. 그러나, 클라이언트가 한번에 드라이버의 하나의 버전만을 실행할 수 있다면, 동일한 드라이버의 상이한 버전을 실행하는 두 서버가 클라이언트와 상호 작용하는 경우 드라이버 불일치가 발생할 수 있다. 클라이언트 기기에 장치 드라이버들이 설치되는 경우, 동일한 이름을 갖는 한 가지 버전의 드라이버 파일들만이 클라이언트 기기에 저장된다. 상이한 두 개의 드라이버 버전들 사이에서 파일 이름이 겹치는 경우, 클라이언트 기기/사용자는 같은 이름을 갖는 두 개의 파일 중에서 하나만을 저장한다 (예를 들면, 보다 최근의 파일 생성 날짜를 갖는 파일 버전). 그 결과, 하나의 드라이버의 상이한 버전들을 실행하며 클라이언트가 그 서버들로 주변장치 연결을 갖는 복수의 활성화된 서버들(active servers) 중 하나에 대해서만 완전한 클라이언트-서버 드라이버 호환성이 보장된다. 따라서 이는, 활성화된 드라이버 디렉토리 내의 다른 드라이버 컴포넌트 버전들로 교체된 하나 이상의 컴포넌트 버전을 포함하는 장치 드라이버 버전을 실행하는 주변장치 서버와 관련해 기능의 손상을 유발한다. 활성화된 드라이버들의 교체는, 클라이언트 기기 상의 복수의 레벨들 중 어느 레벨에서든지 발생할 수 있는데, 이러한 레벨들은 (1) 하나의 드라이버 버전의 컴포넌트들이 두 번째 드라이버 버전과 상이한 드라이버 레벨, (2) 버전들 간에 컴포넌트의 내용이 상이 한 드라이버 컴포넌트 레벨, 및 (3) 동일한 이름을 갖는 파일의 두 가지 버전들의 내용이 상이한 드라이버 파일 레벨을 포함한다.

드라이버/컴포넌트/파일들의 버전들의 덮어쓰기(overwrite)로부터 발생할 수 있는 호환불가/기능 손상의 예는, 구성적 특징(configuration features), 동작, 및 사용자 인터페이스가 지원되지 않는 것을 포함한다.

본 발명은 네트워크 주변장치 환경의 기기들 상에서 드라이버들의 잠재적으로 상이한 버전들 및 이들과 관련된 컴포넌트 버전들을 유지보수하는 것에 관한 종래 기술의 여러 단점들을 해결하기 위해 노력한다. 동시에 활성화된 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 방법이 개시된다. 이 방법은, 예를 들어, 동시에 활성화된 복수의 네트워크 주변장치 드라이버들 중에서 상이한 드라이버들이, 동일한 이름을 갖는 상이한 주변장치 드라이버 컴포넌트 및/또는 파일을 잠재적으로 포함하는 경우에, 모든 네트워크 주변장치/서버들과의 호환성을 보장하도록 네트워크 기기에 의해 수행된다.

이 방법은 상기 기기에 의해 수행되는 이하의 단계들을 포함하는 방식으로 새로운 드라이버를 그 기기에 저장하는 것을 포함한다. 처음에, 기기는 네트워크 주변장치 드라이버의 적어도 하나의 컴포넌트의 버전을 구성하는 일련의 드라이버 파일들을 저장하기 위한 컨테이너를 설정한다. 이어서 그 컨테이너에 고유 식별자 명칭(unique identifier name)이 할당된다. 그 후 일련의 드라이버 파일들이 그 컨테이너 내에 삽입된다.

본 발명의 다른 태양에 따라서, 상기 기기는 멀티-레벨의 활성화된 네트워크 장치 드라이버 접속/저장 프레임워크(multi-level active network device driver access/storage framework) 내부의 활성화된 드라이버들을 유지보수한다. 이 프레임워크는 고유하게 식별되는 일련의 드라이버 버전들을 포함하는 드라이버 버전 식별 레벨을 포함한다. 제2 레벨에서, 각각의 고유하게 식별된 드라이버 버전은 네트워크 주변장치 드라이버의 한 버전을 구성하는 일련의 드라이버 컴포넌트들을 참조(reference)한다. 본 발명의 일 실시예에서, 상기 컴포넌트들은 일련의 파일들을 포함한다. 이 드라이버 컴포넌트 버전들을 구성하는 파일들은 그 컴포넌트 버전들로 할당되는, 고유하게 식별되는 서브-디렉토리에 저장된다. 드라이버 컴포넌트들의 그러한 고유한 식별은 네트워크 시스템의 활성화된 드라이버 저장장치 상에 컴포넌트의 후속 버전이 로딩되는 경우, 드라이버 파일의 제1 버전이 그와 동일한 이름을 갖는 드라이버 파일의 제2 버전을 덮어쓰는 것을 방지하도록 돕는다.

첨부된 특허청구범위가 본 발명의 특징을 구체적으로 설명하는 한편, 본 발명 및 그 장점은 첨부된 도면을 참조하여 후술되는 발명의 구성으로부터 가장 잘 이해된다.

본 발명은, 설명하자면, 클라이언트들, 서버들, 및 네트워크 주변장치들(예컨대, 프린터, 스캐너 등)을 포함하는 네트워크 컴퓨터 시스템 환경에서 구현된다. 본 발명은, 예를 들어, 요청을 하는 클라이언트들 상에 주변장치 드라이버를 설치하기 위한 포인트-소스(point-source)로서 동작하는 중앙 드라이버 패키지 저장소(centralized driver package store)를 포함하는 네트워크에서 수행된다. 이 중앙 드라이버 패키지 저장소는, 네트워크 주변장치에 대해 서버들과 통신하기 위하여 클라이언트들에 의해 사용되는 복수의 드라이버/버전들을 잠재적으로 포함하는 완전한 드라이버 패키지의 버전들을 유지보수(maintain)한다.

또한, 본 발명의 일 실시예에서, 드라이버 패키지 저장소에 설치된 패키지들의 완전성(completeness)이 보장된다. 드라이버들의 완전성은, 요청하는 클라이언트 기기들로 차후에 분배하기 위하여, 또는 패키지로부터 드라이버들을 설치하기 위하여, 그 패키지가 중앙 드라이버 저장소 또는 다른 어떤 기기상에 설치될 때 그 드라이버 패키지와 관련된 모든 일련의 파일들을 복사함으로써 보장된다. 중복된(redundant) 파일들을 삭제하려는 시도는 없다. 설치된 패키지로서 모든 드라이버 관련 파일들을 완전하고, 선택적이지 않게(non-selective) 저장함으로써, 클라이언트 기기가 드라이버들의 설치를 요청할 때 요청된 특정 드라이버와 관련된 일련의 파일들의 호환성 및 완전성이 모두 보장된다.

본 명세서에서 개시된 드라이버 저장장치 및 관리 스킴의 또 다른 태양은 시스템 상의 활성화된 드라이버들을 유지보수하기 위한 새로운 방식을 포함한다. 본 발명의 일 실시예에서, 고유한 드라이버 버전의 적어도 일부를 구성하는 일련의 관련된 파일들은 고유 식별자 명칭을 갖는 디렉토리 컨테이너에서 유지된다. 본 명세서에서 인용된 바와 같은 고유 식별자 명칭은, 동일한 식별자 이름을 갖는 컨테이너들은 정말로 일치한다는 점에 대해 고도의 확신을 제공한다. 고유 식별자 명칭 하에서, 드라이버 버전의 적어도 일부를 구성하는 파일들을 그룹지음으로써, 드 라이버의 상이한 버전들이 클라이언트 시스템 상에서 동시에 활성화될 수 있다.

고유 식별자 명칭은 다수의 상이한 형태로 될 수 있다. 이러한 고유 식별자 명칭의 한 예는 .NET 어셈블리의 문맥에서 사용되는 강력한 이름(strong name)이다. 대안적으로, 드라이버의 소정의 버전을 고유하게 식별하기 위해 GUID + 버전 결합(GUID + version combination)을 사용함으로써 적합한 기능을 얻을 수 있다. 이와 유사하게, 드라이버의 각각의 버전으로 할당된 GUID는 그 자체에 의해 고유 식별자 명칭으로서 사용될 수 있다. 드라이버/파일의 버전을 나타내는 GUID가 상이한 두 드라이버/파일들이 동일한 드라이버/파일의 두 버전에 불과한 것인지 여부의 결정을 쉽게 하도록 돕지는 않기 때문에, 드라이버 관리의 관점에서 최소한 드라이버/제품 GUID를 버전 식별자(version identifier)와 함께 사용하는 것이 일반적으로 선호된다. 또 다른 일 실시예에서, 특정한 드라이버 또는 그의 컴포넌트/파일의 소스의 인증을 용이하게 하기 위해, 공개 키의 해시(hash of public key)와 같은 보안/인증 세그먼트(security/authenticity segment)가 고유 식별자 명칭에 더해진다.

본 명세서에서 개시된 바에 따라, 상이한 드라이버의 구성 파일들을 포함하여 드라이버의 상이한 버전들을 식별하기 위해 고유 식별자 명칭을 사용함으로써 클라이언트 기기가, 동일한 주변장치 드라이버의 상이한 버전들을 실행하는 서버들과 연관된 주변장치(예컨대 프린터) 연결을 동시에 지원할 수 있게 한다. 두 개의 상이한 서버 상에서 실행되는 그러한 상이한 버전들의 예는 두 개의 서버가 동일한 이름을 갖는 드라이버 DLL 파일의 상이한 버전들을 사용하는 경우가 될 것이다. 두 개의 드라이버 DLL 파일 중에서 하나를 덮어쓰기보다는, 본 발명은 각각의 상이한 두 개의 DLL 파일이 그들 각자만의 고유하게 식별되는 디렉토리에 저장되도록 한다.

기존의 .NET 어셈블리 방식(.NET assembly conventions)을 사용하는 본 발명의 예시적인 실시예에서, 공유되는 주변장치를 위한 드라이버의 버전이 중앙 드라이버 저장소에 처음 저장되면, 그 드라이버의 특정한 버전에 대하여 강력한 이름이 결정된다. 이 강력한 이름은, 예를 들어, 그 드라이버의 제작자에 의해 제공된다. 한편, 본 명세서에서 설명된 특정한 드라이버 저장 인프라스트럭처/방법에 대한 지식이 없이 드라이버가 만들어진 경우에는, 그 드라이버가 저장될 때, 그 특정 드라이버 버전과 관련된 하나 이상의 파일들로부터 추출된 메타데이터(예를 들면, 버전 번호, 타임스탬프, 체크섬(checksum) 등)를 기반으로 하여 적합한 고유 식별자 명칭이 생성된다. 두 개의 동일하지 않은 파일이 있을 경우, 강력한 이름이 상이할 가능성이 매우 높기 때문에, 동일한 강력한 이름을 갖는 두 개의 파일은 정말로 일치한다는 점에 대해 고도의 확실성이 보장된다. 각각의 다양한 버전 컨테이너들로 할당된 강력한 이름들은, 중앙 드라이버 저장소 및 그 드라이버의 수신자들(예컨대 프린터 클라이언트들)이 그 기기에 이미 잠재적으로 저장된 다른 버전들로부터 드라이버 컴포넌트(예컨대 어셈블리) 버전을 구별할 수 있게 한다.

본 발명의 특정한 실시예에서, 메타데이터 저장소는 설치된 패키지들 및 드라이버들에 관한 정보를 컴팩트 포맷(compact format)으로 저장한다. 컴팩트 포맷(예컨대 데이터베이스)은 클라이언트가 어떤 적합한 주변장치 드라이버의 설치 방법(예컨대 point-to-point)을 통한 드라이버의 설치/활성화를 요청할 때 그 후의 용이한 검색을 촉진한다.

본 발명의 개시된 실시예에서, 주변장치 드라이버 클라이언트들은 드라이버 버전-특정 컨테이너들에 드라이버들의 적어도 일부(컴포넌트들)를 저장한다. 특정한 드라이버가 클라이언트 기기의 활성화된 드라이버 저장소 내에 놓이면, 그 드라이버는 고유 식별자 명칭(예컨대 강력한 이름)을 할당받는다. 앞서 설명한 바와 같이, 강력한 이름은 드라이버의 특정한 버전이 클라이언트에 의해 현재 유지되는 동일한 드라이버의 다른 버전들로부터 쉽게 구별되도록 보장한다 (버전 정보의 삽입은 또한, 예를 들어, 어떤 드라이버가 보다 새 것인지를 기반으로 하는 의사결정을 용이하게 한다). 일단 특정한 드라이버 버전이 수신 클라이언트 기기 상에 활성화되면, 그 특정 드라이버 버전으로 할당된 강력한 이름은 클라이언트 상의 동일한 드라이버의 다른 활성화된 버전들로부터 그 드라이버 버전을 구별하기 쉽게 한다.

드라이버가 설치되는 동안 드라이버 디렉토리로 복사되는 파일들과 동일한 이름을 갖는 드라이버 파일들의 이전 버전들을 잠재적으로 덮어쓰는 클라이언트측 의 드라이버 관리/저장 스킴과는 달리, 본 발명을 구현하는 클라이언트 측 드라이버 관리/저장 스킴은 클라이언트 드라이버 관리 설비가 드라이버들의 다양한 버전들 및 이들과 관련된 컴포넌트/파일들을 구별할 수 있도록 보장한다. 예를 들어, 드라이버의 보다 새로운 버전이 중앙 드라이버 저장소로부터 클라이언트 기기에 설치되는 경우, 클라이언트는 최소한 그 새로운 드라이버 버전과 관련된 새로운 컴포 넌트들을 위하여 그의 드라이버 파일 저장 설비 내에 고유하게 식별되는 컨테이너(예컨대 파일 시스템 서브-디렉토리)를 생성한다. 본 발명의 일 실시예에서, 새로운 디렉토리 아래에 일련의 드라이버 컴포넌트들 전부가 저장되기보다는, 동일한 드라이버 컴포넌트의 버전들을 서로 구별하기 위해 고유 식별자 명칭을 갖는 새로운 컨테이너 내에 새로운 컴포넌트 버전만이 저장된다. 이전에 설치된 동일한 드라이버 컴포넌트의 오래된 버전은 그 자체의 고유하게 식별되는 컨테이너에서 유지되고, 변경되지 않는다. 그 결과, 네트워크 주변장치(예로 프린터) 클라이언트는, 현재 네트워크 프린터 드라이버의 상이한 두 개의 버전(예로, 1.1 및 1.2)을 실행하는 두 개의 개별 네트워크 장치 서버로의 접근을 동시에 지원할 수 있다.

도면들을 참조하면, 도 1은 본 발명이 편입되는 공유 네트워크 주변장치 환경에서 중앙 드라이버 패키지 저장소, 주변장치 클라이언트들 및 서버들을 구현하기 위한 적합한 운영 환경(100)의 한 예를 도시적으로 나타낸다. 운영 환경(100)은 적합한 운영 환경의 단지 하나의 예일 뿐이고, 발명의 사용 범위 또는 기능과 관련해 어떤 제한을 시사하는 것도 의도하지 않는다. 본 발명과 함께 사용되기에 적합할 수 있는 다른 잘 알려진 컴퓨터 시스템, 환경, 및/또는 구성(configurations)은 퍼스널 컴퓨터, 서버 컴퓨터, 노트북/휴대용 컴퓨팅 장치, 핸드헬드 컴퓨팅 장치(hand-held computing devices),멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 네트워크 PC, 미니컴퓨터, 대형고속컴퓨터(mainframe computer), 앞의 시스템들 또는 장치들 중 어떤 것이든 포함하는 분산 컴퓨팅 환경 등을 포함하나 이에 한정되지는 않는다.

본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령문(computer-executable instructions)에 의해 수행되는 일련의 단계들 및 프로세스들의 일반적인 문맥으로 설명된다. 일반적으로, 프로그램 모듈들은 특정한 작업을 수행하거나 특정한 추상화 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조, 기타를 포함한다. 예시적인 실시예가 단일 컴퓨터 시스템 상의 로컬 영역에서 실행되는 프로세스를 참조하여 설명되지만, 본 발명은 통신 네트워크를 통해 연결된 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 동작하는 네트워크 노드(network nodes) 내에도 편입될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치들을 포함하는 로컬 및 원격 컴퓨터 저장 매체 모두에 일반적으로 위치할 수 있다.

도 1을 계속 참조하면, 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태로 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 처리 유닛(120), 시스템 메모리(130), 및 시스템 메모리(130)와 처리 유닛(120)을 포함하여 다양한 시스템 컴포넌트들을 연결하는 시스템 버스(121)를 포함할 수 있으나 이에 한정되지는 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변장치 버스(peripheral bus), 및 다양한 버스 아키텍처 중에서 어떤 것이든지 사용하는 로컬 버스를 포함하는 여러 종류의 버스 구조 중에서 어떤 것이어도 무방하다. 예를 들어, 그러한 아키텍처는 ISA(Industry Standard Architecture) 버스, AGP(Accelerated Graphics Port), MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌(Mezzanine) 버스로도 알려진 PCI(Peripheral Component Interconnect) 버스를 포함하나, 이에 한정되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 접근될 수 있는 어떤 이용가능한 매체라도 무방하고, 휘발성 및 비휘발성 매체, 착탈식(removable) 및 고정식(non-removable) 매체 모두를 포함한다. 예를 들어, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있으나 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령문, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보를 저장하기 위한 방법 또는 기술로 구현되는 휘발성 및 비휘발성 매체, 착탈식 및 고정식 매체를 모두 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지털 다용도 디스크(digital versatile disk; DVD) 또는 다른 광학 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 원하는 정보를 저장하기 위해 사용되며 컴퓨터(110)에 의해 접근 가능한 다른 매체를 포함하나, 이에 한정되지는 않는다. 통신 매체는 통상적으로 캐리어 웨이브(carrier wave)와 같은 변조된 데이터 신호(modulated data signal) 또는 다른 전송 메커니즘에서 컴퓨터 판독가능 명령문, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 포함하고, 어떤 정보 전달 매체라도 포함한다.

"변조된 데이터 신호"라는 용어는 그 신호의 특성 세트(characteristics set) 중에서 하나 또는 그 이상을 가지거나 그 신호 내의 정보를 인코딩하기 위한 방식으로 변경된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접-유선 연결(direct-wired conection)과 같은 유선 매체, 및 어쿠스틱(acoustic), RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하나, 이에 한정되는 것은 아니다.

시스템 메모리(130)는 판독 전용 메모리(ROM; 131) 및 랜덤 액세스 메모리(RAM; 132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태로 컴퓨터 저장 매체를 포함한다. 컴퓨터(110)의 구성요소 사이에서, 예컨대 시동(start-up)이 되는 동안, 정보 전송을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(BIOS; 133)은 종종 ROM(131)에 저장된다. RAM(132)은 통상적으로 처리 유닛(120)에 의해 즉시 접근 가능하거나 현재 실행되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들어, 도 1은 운영 체계(134), 응용 프로그램(application program; 135), 다른 프로그램 모듈(136), 및 프로그램 데이터(137)를 나타내지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 또한 다른 착탈식/고정식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1은 고정식, 비휘발성 자기 매체로부터 판독하거나 그것으로 기록하는 하드디스크 드라이브(140), 착탈식, 비휘발성 자기 디스크(152)로부터 판독하거나 그것으로 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 다른 광 매체와 같은 착탈식, 비휘발성 광 디스크(156)로부터 판독하거나 그것으로 기록하는 광 디스크 드라이브(155)를 나타낸다. 이 예시적인 운영 환경에서 사용될 수 있는 다른 착탈식/고정식, 휘발성/비휘발성 컴퓨터 저장 매체 는 자기 카세트, 플래시 메모리 카드, 디지털 다용도 디스크, 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하나 이에 한정되지는 않는다. 하드디스크 드라이브(141)는 통상적으로 인터페이스(140)와 같은 고정식 메모리 인터페이스를 통해 시스템 버스(121)로 연결되고, 자기 디스크 드라이브(151), 및 광 디스크 드라이브(155)는 통상적으로 인터페이스(150)와 같은 착탈식 메모리 인터페이스에 의해 시스템 버스(121)로 연결된다.

앞서 논의되고 도 1에서 도시된 드라이브들 및 이들의 관련된 컴퓨터 저장 매체는 컴퓨터(110)에 대하여, 컴퓨터 판독가능 명령문, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드디스크 드라이브(141)는 강력한 운영체계(144), 응용 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)로서 도시되어 있다. 이들 컴포넌트가 운영 체계(134), 응용 프로그램(135), 다른 프로그램 모듈(136), 및 프로그램 데이터(137)와 같을 수도 있고 다를 수도 있다는 점에 주목하자. 본 명세서에서 운영체계(144), 응용 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 이들이 상이한 사본들(copies)이라는 점을 나타내기 위해 상이한 번호가 부여된다. 사용자는 키보드(162), 및 흔히 마우스, 트랙볼 또는 터치 패드로 불리는 위치 지정 도구(pointing device; 161)와 같은 입력 장치를 통해 컴퓨터(110)로 명령이나 정보를 입력할 수 있다. 다른 입력 장치(도시되지 않음)들은 마이크, 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 이러한 것들과 다른 입력 장치들은 대개 시스템 버스로 연결된 사용자 입력 인터페이스(160)를 통해 처리 유닛(120)과 연결되나, 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 연결될 수도 있다. 모니터(191) 또는 다른 종류의 디스플레이 장치가 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)로 역시 연결될 수 있다. 모니터(191) 외에도, 컴퓨터는 출력 주변장치 인터페이스(195)를 통해 연결될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변 출력 장치들을 포함한다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은, 하나 이상의 원격 컴퓨터로의 논리적인 연결을 사용하는 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치(peer device) 또는 다른 보통의 네트워크 노드(network node)일 수 있고, 도 1에는 메모리 저장 장치(181)만이 도시되어 있지만, 통상적으로 컴퓨터(110)와 관련하여 앞서 설명한 많은 또는 모든 구성요소들을 포함한다. 도 1에 도시된 논리적인 연결은 근거리 통신망(LAN; 171) 및 광역 통신망(WAN; 173)을 포함하지만, 다른 네트워크들도 역시 포함할 수 있다. 이러한 네트워킹 환경은 사무소, 기업용 컴퓨터 네트워크(enterprise-wide computer networks), 인트라넷, 및 인터넷에서는 흔한 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)으로 연결된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 통상적으로 모뎀(172) 또는 인터넷과 같은, WAN(173)에 걸쳐 통신을 구축하기 위한 다른 수단을 포함할 수 있다. 내부적이거나 외부적일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스 템 버스(121)로 연결될 수 있다. 네트워크 환경에서, 컴퓨터(110)와 관련해 서술된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장치에 저장될 수 있다. 예컨대, 도 1은 메모리 장치(181) 상에 유지되는 것으로서 원격 응용 프로그램(185)을 나타내나 이에 한정되는 것은 아니다. 도시된 네트워크 연결은 예시적인 것이고, 상술된 주변장치 드라이버 관리 스킴을 수행하기 위한 다른 수단들이 사용될 수 있음이 인식될 것이다.

도 2는 본 발명의 예시적인 실시예에 따라 네트워크 주변장치(예컨대 프린터) 드라이버 관리 형태(networked peripheral device driver management arrangement)에 참여하는 일련의 네트워크 엔티티들(network entities)을 포함하는 예시적인 네트워크를 도시적으로 나타낸다. 예시적인 컴퓨터 네트워크 환경(200)은 로그인된(logged on) 사용자들을 위해 응용 프로그램들을 실행하는 일련의 클라이언트 기기들(202; 1 내지 n)을 포함한다. 클라이언트 컴퓨터들의 숫자(n)는 일반적으로 적은 수의 컴퓨터들로부터 수백 또는 수천까지도 가능하다. 이러한 네트워크는 사실상 어떤 수의 추가적인 클라이언트 기기들에게든지 네트워크를 열어 두는 광역 통신망 연결(wide area network links)을 가능하다면 포함한다. 클라이언트 기기들(202)은 네트워크 프린터 드라이버들을 통해 프린트 특징(예컨대, 방향(orientation), 해상도, 프린트 모드 등)을 구성하고, 네트워크 연결(210)을 통해 프린트 서버들(204; 205)이 유지하는 프린트 대기열(print queues)로 프린트 요청을 보낸다. 프린트 서버들(204; 205)은 특정한 프린트 대기열로 요청을 보내기 위해 클라이언트 기기들(202)에 의해 사용되는 프린터 드라이버와 대응하는 프 린터 드라이버를 사용하여 그 프린트 요청을 처리한다. 프린트 서버들(204; 205)은 그 특정한 대기열과 관련된 프린터 드라이버를 이용하여, 그 프린트 작업을 가져온 프린트 대기열과 대응하는 적합한 프린터에 대하여 프린트 작업을 렌더링(render)한다. 그 후 프린트 서버들(204; 205)은 클라이언트 기기들(202)을 위하여 네트워크 연결(210)을 통해 일련의 네트워크 프린터들(206, 208) 중에서 (클라이언트의 원래의 프린트 요청에 따른) 적합한 프린터로 렌더링된 프린트 작업을 전달한다. 프린터들(206, 208)은 그 후 프린트 서버들(204; 205)로부터 렌더링된 프린트 작업을 수신하고, 프린터들(206, 208)은 프린트된 문서 출력을 생성한다.

본 발명의 일 실시예에서, 클라이언트 기기들(202)의 클라이언트 컴퓨터는 그의 프린트 요청이 보내질 프린트 서버(예컨대 (204) 또는 (205))와 관련된 적합한 네트워크 프린터 드라이버 컴포넌트들을 먼저 설치하고 활성화한 후 프린트 요청을 내보낸다. 본 발명의 일 실시예에서, 그러한 컴포넌트들은 처음에 (본 명세서에서 도 4a 및 도 4b를 참조하여 후술되는) 드라이버 패키지들의 형태로 네트워크(200) 상의 중앙 드라이버 저장소(212) 내에 유지된다. 중앙 드라이버 저장소(212)는 (압축되지 않은 컴포넌트들을 포함하여) 드라이버들 및 메타데이터를 그 패키지들로부터 렌더링한다. 메타데이터는 그 패키지들 내의 (각각 많은 컴포넌트/파일들을 포함할 수 있는) 패키지들 및 드라이버들을 충분히 상세하게 확인하여, (1) 동일한 패키지/드라이버의 상이한 버전들, 또는 (2) 상이한 장치 드라이버들에 대응하는 동일한 이름의 파일들을 서로 구별한다. 본 발명의 일 실시예에 서, 클라이언트 기기들(202)은 각각의 클라이언트 기기들(202)이 유지하는 활성화된 드라이버 저장소(active driver store; 302)에 저장되는 드라이버들 및 그 드라이버들의 구성 파일들을 식별한다. 중앙 드라이버 저장소(212)로부터 (또는 프린트 서버들(204; 205) 중에서 하나와 같이, 필요한 드라이버와 관련된 완전한 일련의 컴포넌트/파일들을 포함하는 다른 네트워크 장치를 통해 간접적으로) 네트워크 장치 드라이버들의 설치와 함께, 클라이언트 기기들(202)은 각각의 개별 드라이버에 대하여 별개의 컨테이너(예컨대 디렉토리)를 생성한다. 각각의 드라이버 컨테이너로 할당된 개별 라벨은, 적어도 부분적으로, 그 드라이버와 관련된 서명 정보(signature information)로부터 렌더링된다. 그러한 서명 정보는 본 발명의 대안적인 실시예들에서 다양한 형태를 갖는다.

앞서 설명된 네트워크 환경은 본 발명이 유리하게 편입되는 예시적인 컴퓨터 네트워크 환경을 나타낸다. 당업자는, 중복될 수 있는 드라이버 구성 파일 이름들(constituent driver file names)을 갖는 복수의 활성화된 드라이버들(동일한 드라이버의 복수의 버전들을 포함함)의 유지보수가 꼭 필요하지 않더라도, 네트워크 주변장치의 클라이언트를 위해 그 유지보수를 원하는 다양한 경우에 본 발명이 적용될 수 있음을 쉽게 인식할 것이다. 이러한 예시적인 네트워크 환경이 설명되었고, 주변장치 드라이버 패키지들의 내용, 패키지들의 처리, 및 그 패키지로부터 추출된 드라이버의 분배 및 유지보수가 본 발명의 예시적인 실시예에 따라서 후술된다.

도 3으로 가면, 드라이버 저장 장치 형태(arrangement)의 드라이버들 및/또 는 드라이버 정보의 세 가지 표현이 식별된다. 드라이버 패키지 저장소(300)는 예컨대 제작자로부터 전송되는 형태로 드라이버 패키지들을 완전하게 복사하여 저장한다. 일반적으로 패키지는 복수의 컴퓨팅 환경들 및 본질적으로 동일한 드라이버의 상이한 버전들(예컨대, 추가된/수정된 특징들 및/또는 버그 수정을 포함하는 동일한 드라이버의 연속적인 출시)까지도 지원하는 복수의 드라이버들을 포함하도록 의도된다. 드라이버 패키지 저장소(300)는, 본 발명의 일 실시예에서, 중앙 드라이버 저장소(212)에 위치한다. 한편, 그 드라이버 패키지 저장소(300)는 클라이언트 기기 또는 서버 상에 위치할 수도 있다. 어느 경우에서든지, 발명의 일 실시예에서, 분산된 파일 시스템에서 드라이버 패키지 저장소(300)는 공개 디렉토리(공유 파일)에 위치한다. 공간을 보존하기 위하여, 드라이버 패키지들의 내용은 압축된다. 드라이버 패키지 저장소(300)의 예시적인 버전의 컴포넌트들은 본 명세서에서 도 4a 및 도 4b를 참조하여 뒤에서 보다 자세히 설명된다.

발명의 일 실시예에서, 드라이버 파일들은 드라이버 패키지 저장소(300)의 패키지들로부터 추출되어, 활성화된 드라이버 저장소(302) 내에 놓인다. 일반적으로 네트워크의 서버들이나 클라이언트들 상에서 발견되는 활성화된 드라이버 저장소(302)는 로딩되고 압축 해제된 드라이버 파일들을 유지하기 위한 디렉토리 구조이다. 발명의 일 실시예에서, 활성화된 드라이버 저장소(302)의 드라이버 파일들은 네트워크 상의 다른 클라이언트 또는 서버 기기에 의해 접근될 수 있는 분산된 파일 시스템 공유(distributed file system share)를 통해 유지된다. 이러한 실시예에서, 클라이언트 또는 서버 기기 상의 활성화된 드라이버 저장소(302)는 그 기 기의 저장 공간 내의 다른 비공개 컴포넌트들과는 분리된다. 예시적인 드라이버 저장소(302)의 형태 및 기능은 도 5a 및 도 5b를 참조하여 본 명세서에서 후술된다.

네트워크 주변장치 드라이버 유지보수 프레임워크의 일 실시예에서, 메타데이터 저장소(304)는, 로컬 기기 상에 로딩되거나 그 기기에서 이용 가능한 드라이버들의 키-기반 배치 및 검색(key-based arrangement and searching)을 지원하는 데이터베이스를 포함한다. 발명의 한 실시예에서 메타데이터 저장소(304)는, 또한 각각의 드라이버 버전에 대해, 그 특정 드라이버 버전을 구성하는 일련의 컴포넌트들을 열거하는 매니페스트(manifest)를 포함한다. 키로 검색 가능한 분야는, 예를 들어, 환경(environment), 제작자, 드라이버, 및 패키지를 포함한다. 예시적인 데이터베이스 스키마는 본 명세서에서 도 6을 참조하여 후술된다.

도 4a로 보면, 드라이버 패키지 저장소(300)의 드라이버 패키지는 다양한 형태를 취할 수 있다. 한편, 예시적인 실시예에서, 드라이버 패키지는 세 개의 주요 부분을 포함하며 이는 INF 파일(400), CAT 파일(410) 및 드라이버 소스 파일들이 압축되어 위치하는 CAB 파일(420)이다. INF 파일(400)은 드라이버 패키지의 내용을 설명한다. 발명의 일 실시예에서, 이 INF 파일(400)은 패키지 ID 및 버전에 의해 패키지를 식별하는 고유한 ID를 포함하며 이는 동일한 드라이버 패키지의 버전들 사이의 구별을 용이하게 한다. 이 버전은, 예를 들면, INF 파일(400)의 드라이버 버전 필드(driver version field) 내로 삽입되는 타임스탬프(연/월/일)에 의해 지시된다. 대안적으로, 특정한 패키지 버전에 대한 고유한 ID는 CAT 파일(410)또 는 CAB 파일(420) 내부의 해싱 서명 정보(hashing signature information)로부터 생성된다. 이 버전의 또 다른 예는 주요 버전/부수적인 버전 및 버그수정판(bugfix) 릴리즈를 식별하는 복수의 세그먼트들을 포함하는 정식 버전 코드(formalized version code)이다. 적합한 버전을 식별하는 여러 다양한 정보에 의해 증명된 바와 같이, 본 발명은, 일치하는 버전 값들을 갖는 두 개의 패키지는 정말로 동일한 패키지라는 점에 대해 고도의 확실성을 제공하는 패키지-관련 데이터/메타데이터의 사용을 고려한다. 본 명세서에서는 그러한 식별 부호(identification)를 "강력한 이름(strong name)"이라고 부른다.

INF 파일(400)은 드라이버 패키지의 CAT 파일(410)에 접근하기 위해 설치자(installer)로의 방향(direction)을 포함한다. CAT 파일(410)은 패키지를 인증하는 고유 서명을 포함한다. CAT 파일(410)은 또한, 예를 들어, 서명이 유효하게 되는 플랫폼을 식별하는 메타데이터 및 그 서명을 생성하기 위해 사용된 증명서들(certificate)을 포함하나, 이에 한정되는 것은 아니다. CAT 파일(410)을 식별하는 것 외에도, INF 파일(400)은 하나 이상의 드라이버 어셈블리(특정한 드라이버 버전을 구성하는 관련된 파일의 그룹)를 렌더링하기 위해 그 드라이버 패키지 내의 파일들을 어떻게 배치할 것인지를 기술한다. 이 INF는 또한 플러그-앤-플레이 ID를 포함한다. 발명의 일 실시예에서, 실제의 드라이버 파일들은 CAB("캐비넷(cabinet)") 파일(420)로 압축된 형태로 구비된다.

이하는 INF 파일(400)의 간단한 예이다.

예시적인 INF 파일은 세 개의 개별 운영체계에 대한 방향들을 포함한다. 세 번째 (Foo.NT.6.0)는 패키지로부터 파일을 로딩하는 것과 관련된 추가된 메커니즘을 이용한다. "Install Package"는 현재의 패키지와 함께 설치되어야 하는 다른 패키지에 대한 INF를 식별한다. 컴포넌트들 (.NET 어셈블리들이 이 컴포넌트의 특정한 예이다) 은 드라이버의 구성요소(building blocks)이고, 복수의 파일들과 다른 컴포넌트들까지도 포함할 수 있다. 매니페스트는 드라이버의 강력한 이름 및 그 드라이버 컴포넌트들(예컨대 .NET 어셈블리들)의 강력한 이름들을 포함한다.

발명의 일 실시예에서, Unidrv만을 포함하는 패키지가 지원되고, INF가 그 정보를 전달한다. 본 발명의 일 실시예에서, 이러한 요청은 "CompName"=CompGUID 를 포함하는 섹션 태그 [PrintSoftwareComponents]에 의해 충족된다. 모든 컴포넌트는 CompGuid로 명명된 섹션에서 기술된다.

예를 들면 다음과 같다.

패키지들은 구성 가능한 위치에서 드라이버 패키지 저장소(300)에 저장된다. 디폴트로, 드라이버 패키지 저장소는 로컬 기기(예컨대 중앙 드라이버 저장소(212)) 상에 존재한다. 그러나 본 발명의 일 실시예에서, 드라이버 패키지 저장소(300)의 내용은 다른 네트워크 기기들에 의해 접근 가능하게 된다. 그러한 접근 가능성은, 예를 들어 네트워크 상의 다른 기기들로 공개되는 분산된 파일 시스템 공유 상에 패키지 저장소(300)를 위치함으로써 구현된다.

도 4b로 가면, 계층적 트리 구조도가, INF 파일(400)에서 규정된 바와 같이, 드라이버 패키지 저장소(300) 내부의 드라이버 컨테이너들(예컨대, 패키지, 드라이버, 어셈블리 등) 및 파일들의 계층적인 배치/연결을 나타낸다. 상이한 드라이버 어셈블리들에서 여러 번 사용된 파일의 경우에는, 단일한 사본이 패키지 내에 잠재적으로 저장되고, 메모리를 보존하도록 그 단일한 드라이버 사본에 대한 연결들(links)이 그 패키지 내로 저장된다는 점에 주의하자. 대안적으로는, 각각의 어셈블리에 대하여, 이와 관련된 파일의 완전한 사본이 저장된다.

공유 드라이버 패키지 저장소(300)의 최고 레벨에서, 드라이버 패키지들의 컨테이너(450)는 공유 디렉토리의 루트에 해당한다. 그 다음 레벨에서, 패키지GUID로 구분되는 일련의 패키지 컨테이너들(packageGUID-delimited package containers; 460; 462; 및 464)은 고유하게 식별되는 패키지들의 잠재적으로 복수 인 버전들을 유지한다. 패키지들은 각각의 패키지에 대한 별개의 GUID에 의해 구별된다. 예시적인 실시예에서, 패키지 컨테이너(460)는 두 개의 패키지(470; 472)들을 유지하고, 각각의 패키지는 도 4b에서 나타난 디렉토리 구조에서, 각각의 특정한 패키지 버전으로 할당되는 강력한 이름(예컨대 패키지 날짜(package date))에 의해 고유하게 식별된다. 강력한 이름보다는 GUID+version 방식이 사용되는 발명의 일 실시예에서, 도 4b의 계층적 트리는 이하의 디렉토리 배치와 대응된다.

Root＼{PackageGUID1}＼PackageDate1＼ :제1 패키지의 하나의 버전 포함

Root＼{PackageGUID1}＼PackageDate2＼ :제1 패키지의 새로운 버전 포함

Root＼{PackageGUID2}＼PackageDate3＼ :제2 패키지의 버전 포함

...

Root＼{PackageGUIDn}＼PackageDate4＼ :제n 패키지의 버전 포함

발명의 일 실시예에서, 패키지 날짜의 형식은 yyyymmdd 이다. 또 다른 예시적인 실시예에서, 드라이버 패키지 버전들을 식별/구별하기 위하여 강력한 이름 또는 GUID 값이 단독적으로 사용된다.

또한, 도 4b에서 도시된 바와 같이, (고유 식별자 명칭으로 식별되는) 특정한 드라이버 버전들을 구성하는 컴포넌트들을 열거하는 드라이버 매니페스트와 같은 비-드라이버 컴포넌트 특정 파일(non-driver component specific file)을 포함하는 것 외에도, 패키지(472)는 각각의 드라이버 컴포넌트 A 및 드라이버 컴포넌트에 대하여 드라이버 컴포넌트-특정 컨테이너들(480; 482)을 특정한다. 대안적으로, 각각의 드라이버는 그 자체의 컨테이너가 주어진다 (그러나 이는 패키지 내의 상이한 많은 드라이버들에 대해 컴포넌트들이 공통되는 경우에는 덜 바람직하다). 발명의 일 실시예에서 드라이버 컴포넌트-특정 컨테이너들(480; 482)은, 예를 들어 상이한 드라이버 소프트웨어 제공자들에 의해 분배되는, 동일한 이름을 갖는 드라이버 컴포넌트들을 구별하는 모델-및-제공자 GUID(model-and-provider GUID; MPG)의 결합에 의하여 특정된다. 드라이버 컴포넌트-특정 컨테이너(480; 드라이버 A)는, 이어서 드라이버 컴포넌트 A의 버전 1 및 버전 2에 대응하는 두 개의 버전 컨테이너(490; 492; 예컨대 어셈블리들)들을 포함한다. 본 발명의 일 실시예에서 어셈블리는, 그 드라이버의 기능(functionality)을 수행하기 위하여 함께 그룹지어진 일련의 하나 이상의 파일들을 포함한다.

본 발명의 예시적인 실시예에서, 드라이버 버전을 다른 드라이버 버전으로부터 구별하는, 그 드라이버 버전의 적어도 일부(예컨대 컴포넌트)가 분리되어 개별적으로 라벨이 붙여진 컨테이너에 저장된다. 이러한 배치는 네트워크 주변장치 클라이언트가 드라이버의 복수의 개별적인 버전들을 지원할 수 있게 한다. 발명의 특정한 실시예에서, 드라이버 컴포넌트의 특정한 버전을 구성하는 파일들은 어셈블리의 형태로 함께 그룹지어진다. 각각의 어셈블리는, 동일한 드라이버의 상이한 버전들와 관련된 어셈블리들에게 상이한 라벨이 할당되도록, 개별적으로 라벨 붙여진 컨테이너(예컨대 디렉토리 서비스 서브-디렉토리)로 할당된다.

드라이버 컴포넌트(예로서 어셈블리) 버전들은 각각의 드라이버 어셈블리 컨테이너에 고유 식별자 명칭을 가지고 라벨을 붙임으로써 구별된다. 이 고유 식별자 명칭은 특정한 드라이버의 상이한 두 버전을 구별할 확률이 높은 어느 적합한 식별자이다. 특정한 예시적인 실시예에서, 고유 식별자 명칭들은 .NET의 강력한 이름들이다. 강력한 이름들은 특정한 드라이버 버전의 적어도 일부를 구성하는 관련된 드라이버 파일(예컨대 어셈블리) 그룹들에 할당된 버전 날짜들(version dates)을 포함한다. 대안적으로, 버전은 a.b.c.d의 형태(a.b.는 특징 버전 번호(feature version number)를 나타내고, c.d.는 버그수정 번호를 나타냄)로 표시되는 64-비트 값의 형태로 제공된다. 또 다른 실시예에서, 강력한 이름들은 드라이버 버전을 다른 드라이버 버전들로부터 구별하는 정보를 기초로 수행되는 체크섬(checksum) 또는 해싱 동작(hashing operation)을 기반으로 한다.

도 5a에서, 일반적으로 네트워크에서 서버들 및 클라이언트들 상에서 발견되는 활성화된 드라이버 저장소(302)는 로딩 및 압축-해제된 드라이버 파일들(502) 및 매니페스트 정보(504)를 유지한다. 발명의 일 실시예에서, 두 가지 형태의 매니페스트가 사용된다. 이들은 (1) 컴포넌트의 내용을 기술하는 컴포넌트 매니페스트(예컨대, 컴포넌트 및 다른 필요한 컴포넌트들을 구성하는 파일들을 식별함), 및 (2) 드라이버의 컴포넌트들을 기술하는 드라이버 매니페스트(필요한 컴포넌트들만이 기술되며, 드라이버 그 자체가, 컴포넌트의 일부가 아닌 어떤 파일도 갖지 않기 때문에 파일 정보는 기술되지 않음)이다. 발명의 일 실시예에서, 각각의 드라이버 컴포넌트의 각각의 버전은 그 자체의 고유하게 식별되는 컨테이너(예컨대 서브-디렉토리)를 활성화된 드라이버 저장소(302) 내에 할당받는다. 또한 활성화된 드라이버 저장소(302)는, 그 활성화된 드라이버 저장소(302)에 유지되는 각각의 특정한 드라이버 컴포넌트 버전(컨테이너)과 관련된 파일들의 그룹을 설명하고/열거하는, 매니페스트 정보(504)를 매 컨테이너마다 포함한다.

발명의 일 실시예에서 매니페스트 정보(504)는 또한, 드라이버 버전을 구성하는, 활성화된 드라이버 저장소(302) 내의 컴포넌트들을 식별하는 (각각의 드라이버 버전에 대한) 고유 식별자들에 의해 라벨 붙여진 파일들 내의 목록들을 포함한다. 각각의 특정한 드라이버 버전은 그 자체의 고유하게 식별되는 컨테이너(예컨대 파일)를 구비하며, 이 컨테이너는 그 드라이버 버전의 컴포넌트들을 열거하는 드라이버 매니페스트만을 포함한다 (다른 파일들을 포함하지 않는다). 본 발명의 일 실시예에서, 드라이버 매니페스트 컨테이너들(파일들)은 활성화된 드라이버 저장소(302) 내에 위치하거나, 대안적인 실시예에서 다른 적절한 위치(메타데이터 저장소(304)의 드라이버 버전 테이블을 포함)에 위치한다. 각각의 드라이버/컴포넌트 컨테이너에 대한 고유 식별자 명칭은, 예를 들어, 동일한 드라이버/컴포넌트의 상이한 두 개의 버전들이 상이한 컨테이너 이름을 가질 것을 보장하기 위해, 그 드라이버/컴포넌트 버전들로부터 추출가능한 특징적 데이터의 결합을 기반으로 하여 생성되는 고유한 이름이다. 본 명세서에서 앞서 언급한 바와 같이, 그러한 고유 식별자 명칭의 예는 (1) 강력한 이름, 및 (2) 모델-및-제공자 GUID(MPG) 및 버전의 결합이다.

발명의 일 실시예에서, 특정한 드라이버에 대한 문맥을 설정하기 위한 버전 정보(versioning information)를 포함하는 컴포넌트 설명들은, 특정한 드라이버 컴포넌트 버전이 활성화된 드라이버 저장소(302)에 저장될 때 매니페스트 정보(504)로 저장된다. 그 후, 특정한 드라이버를 사용하는 서비스 또는 애플리케이션은, 드라이버 컴포넌트 파일들을 로딩하기 전에, 매니페스트 정보(504)를 기반으로 하여 문맥을 설정한다. ("활성화 문맥"으로도 알려진) 이 문맥은 특정한 파일 버전/어셈블리를 로딩하기 위해 애플리케이션을 재지시(redirect)하도록 시스템이 사용할 수 있는 정보를 포함하는, 메모리의 데이터 구조이다. 이러한 경우 문맥은 드라이버의 매니페스트 파일로부터 생성된다. 이 문맥은 파일들(예컨대 DLL들)의 잠재적으로 많은 버전들 중에서 어떤 버전이 특정한 드라이버 버전에 대하여 사용되어야 하는지를 정의한다. 문맥은 예를 들어, 관리자(administrator)에 의해 무효로 될 수 있다(overridden).

이하는 활성화된 드라이버 저장소(302)의 드라이버 파일들(502) 내의 두 개의 개별 서브-디렉토리 컨테이너로 할당된 특정한 드라이버 컴포넌트/어셈블리(두 개의 관련 파일 포함)의 두 버전에 대한 두 개의 매니페스트 정보(504) 엔트리를 나타낸다.

어셈블리 1: Foo.dll (v x.y)

Fooui.dll (v a.b)

어셈블리 1': Foo.dll (v x.y')

Fooui.dll (v a.b')

...

어셈블리 1'는 Foo.dll 및 Fooui.dll 모두의 상이한 버전을 갖는다. 발명의 일 실시예에서, 특정한 드라이버 컴포넌트의 두 세트의 파일들 간의 차이는, 드라이버 파일들(502)의 서브-디렉토리와 대응하는 고유한 개별 매니페스트를 갖는 개 별 컴포넌트들(어셈블리들)의 설정을 가져온다.

발명의 일 실시예에서, 활성화된 드라이버 저장소(302)의 드라이버 파일들(502)은 네트워크 상의 다른 클라이언트 및 서버 기기들에 의해 접근 가능한 분산된 파일 시스템 공유에서 유지된다. 그러한 실시예에서, 클라이언트 또는 서버 기기 상의 활성화된 드라이버 저장소(302)는 기기의 저장 공간 내의 다른 비공개 컴포넌트들로부터 분리된다. 분산된 파일 시스템 공유에서 드라이버 파일들(502)의 배치는 매니페스트 정보(504)에 의해 식별되는 어셈블리들에 대응한다.

도 5b에서, 도면은 본 발명이 특별히 유용하게 되는 예시적인 경우를 도시적으로 나타낸다. 즉 클라이언트(540)가 동일한 드라이버("Foo")의 두 개의 상이한 버전("x" 및 "y")을 실행하고 있는 제1 서버(550) 및 제2 서버(560)로 두 개의 상이한 연결을 유지하고 있는 경우이다. 이 예시적인 경우에서, 클라이언트(540)는, (드라이버 버전 x(556)를 실행하는) 서버(550) 및 (드라이버 버전 y(566)를 실행하는) 서버(560) 모두와의 완전한 동시적 호환성(complete simultaneous compatibility)을 달성하기 위하여, 대응되는 네트워크 주변장치들(570; 580)과 연관된 주변장치 설정들을 취급할 때, 드라이버 Foo(555)의 버전 x 및 드라이버 Foo(565)의 버전 y를 동시에 활성 상태로 유지하는 능력을 이용한다. 그러한 설정들은 서버들(550; 560)의 설정들(557; 567)에서 개별적으로 지속된다. 지속되는 설정들(557; 567)의 사본은 클라이언트(540) 상에 유지되는 설정들(558; 568)로 각각 복사된다. 완전한 드라이버 버전 호환성을 갖는데 실패할 경우, 클라이언트(540)는 서버들(550; 560) 상의 설정들(558, 568)을 해석(interpret)할 수 없게 될 수 있다.

도 6에서, 데이터베이스 스키마는 예시적인 드라이버 관리 설비의 메타데이터 저장소(304)의 예시적인 배치를 나타낸다. 본 명세서에서 앞서 언급한 바와 같이, 메타데이터 저장소(304)는 적어도 하나의 클라이언트 기기 상에 유지되고, 그 기기 상에 로딩된 활성화된 드라이버들을 규칙적인 방식으로 요약한다. 메타데이터 저장소(304)가 본 발명을 수행하기 위해 필요한 것은 아니다. 그러나, 이의 존재는 네트워크 환경에서 주변장치 드라이버들의 대형 집단을 관리하기 위한 편리한 방법을 제시한다. 본 발명의 일 실시예에서, 메타데이터 저장소(304)는 스풀러 서비스(spooler service)에 의해 관리된다.

도 6에서 요약된 예시적인 데이터베이스 스키마는 아래와 같이 배치되고 접근된다. Packages 테이블(패키지 테이블; 600) 내의 엔트리들은 "PackageID"를 제출(submit)함으로써 CompPackLookup 함수(610)에 의해 참조된다(referenced). Packages 테이블(600) 내의 엔트리들에 대하여 제공되는 서브-필드들(sub-fields)은 packageGUID, 버전, 및 각각의 식별된 패키지에 대한 INFName을 포함한다.

CompPackLookup 함수(610)는 또한 "ComponentID"를 통해 Components 테이블(620) 내의 엔트리들로 접근한다. 컴포넌트들은, 이를 열거하면, EnvID, ComponentGUID, ComponentName 및 버전을 포함한다. EnvID 필드는 Environments 테이블(630) 상에서 검색 키(search key)로 사용될 수 있는 값을 제공한다. Environments 테이블(630) 엔트리들은 식별된 Environment(예를 들어, Windows NT x86, Windows NT IA64 등)에 대응하는 EnvName을 포함한다.

고려되는 다른 테이블 엔트리 검색 함수는 PhysDriverComponentLookup 함수(640)이다. 이 PhysDriverComponentLookup 함수(640)는 ComponentID 검색 키를 통해 Components 테이블(620)의 엔트리에 접근한다. PhysDriverComponentLookup 함수(640)는 또한 PhysDriverID 검색 키를 통해 PhysicalDrivers 테이블(650)에 접근한다. PhysicalDrivers 테이블(650)의 물리적 드라이버 엔트리들(physical driver entries)은, 열거하면, LogDriverID(논리적인 드라이버 ID), EnvID, 및 LanguageID를 포함한다. EnvID 필드는 Environments 테이블(630)을 검색하기 위한 값을 제공한다. 또한, LogDriverID 필드는 LogicalDrivers 테이블(660)을 검색하기 위한 값을 제공한다. 발명의 일 실시예에서, PhysicalDrivers 테이블(650)은 또한 각각의 고유하게 식별된 물리적인 드라이버/버전 결합에 대한 드라이버 매니페스트 목록을 저장한다.

따라서, 본 발명의 일 실시예에서 논리적인 드라이버는 특정한 플랫폼에 대하여 컴파일된 드라이버로부터 추상화되거나, 특정한 사용자 언어(예컨대 영어)로 현지화된(localized) 드라이버를 말한다. 물리적인 드라이버는, 특정한 환경에 대하여 컴파일되고 어떤 언어에 대하여 현지화되는데, 그 식별된 특정한 환경(예컨대 "Windows NT x86", "Windows NT IA64") 및 가능하게는 그 언어에 첨부된다. 식별된 물리적인 드라이버는 다수의 컴포넌트들(예컨대 HP 레이저젯 4 커스텀화(HP LaserJet 4 customization), sRGB 프로필 및 Unidrv)을 포함할 수 있다. 모든 컴포넌트들이 특정한 환경(예컨대 Image Color Management (ICM) 프로필, 또는 GPD(generic printer description))에 의존하는 것은 아니라는 점에 주목할 것이다.

LogicalDrivers 테이블(660)은 DriverName(드라이버 이름), ManuID(제작자 ID), PnpID(플러그-앤-플레이 ID), 버전, 및 ProviderID(제공자 ID)를 포함한다. 제작자 ID는, 이어서, Manufacturers 테이블(670)내의 엔트리들을 참조한다. Manufacturers 테이블(670)의 필드는, 예를 들어, 이름 필드 및 URL 필드를 포함한다.

발명의 일 실시예에서, 메타데이터 저장소(304) 데이터베이스는 드라이버 저장을 제공하는 서비스의 처음 부트(boot) 시에 생성된다. 발명의 일 실시예에서, 프린트 스풀러가 그러한 서비스를 제공한다. 다른 예에서는 전용 드라이버 관리 서비스가 사용된다. 메타데이터 저장소(304) 데이터베이스는 운영 체계의 사본과 함께 구비되는 INF 파일들의 내용으로부터 채워진다. 대안적으로, 미리 채워진 데이터베이스가, 구축 프로세스를 복잡하게 하는 대가를 치르면서 구축 단계로 로딩된다 (데이터베이스 내의 정보가 INF들에 있는 정보와 중복되기 때문에 이는 새로운 후-구축 단계(post-build step)가 되어야 할 것이다).

앞서 언급한 바와 같이, 패키지 테이블과 관련해, (패키지의 INF에 의해 제공되는) 대개 PackageID는, (INF가 변경되지 않는 한) 패키지 전체에 변경이 있을 때마다 변경되지는 않기 때문에, 실질적으로 동일한 패키지의 두 개의 버전들을 구별하는데 있어 PackageID가 신뢰성을 가지고 사용될 수는 없다. 대신, INF에 의해 설정되는 PackageID는 일단 패키지가 생성되면 (버전들 사이에서도) 변경되지 않는 다. 따라서, 패키지에 저장된 DriverVer 엔트리가 동일한 PackageID 값을 갖는 패키지의 두 개의 버전을 서로 구별하는데 사용된다.

네트워크 환경에서 클라이언트에 의해 사용되기 위한 주변장치 드라이버 유지보수 설비의 근본 조직을 설명했으므로, 이제 시스템의 기능적인 인터페이스들, 및 본 명세서에서 설명된 근본 프레임워크를 사용하여 수행되는 방법들로 관심을 돌려본다. 도 7로 가면, 일련의 예시적인 (프린터 드라이버 관련) 응용 프로그램 인터페이스(application program interfaces; APIs)가 패키지들 및 드라이버들을 로딩/설치하기 위하여 식별된다. 이 API들은 예를 들어, 원격 절차 호출 헬퍼 라이브러리(remote procedure call helper library)를 사용하여 구현된다. 그 결과, 모든 주변장치 제공자들에 의해 기능들이 구현될 필요가 없다.

UploadPrinterDriverPackage() API(700)

UploadPrinterDriverPackage() API(700)은 프린터 드라이버 패키지들의 업로딩을 촉진한다. UploadPrinterDriverPackage() API(700)은 비동기(asynchronous) API이다. 다음은 UploadPrinterDriverPackage() API(700)의 예시적인 형태이다.

이하는 인용된 파라미터들의 특성을 나타낸다.

pszServer는 패키지가 업로딩되어야 하는 서버의 전체 이름이다. 서버가 클러스터인 경우에는, 이 파라미터는 그 클러스터 이름으로 시작되어야 한다.

pszINFPath는 프린터 드라이버 패키지를 생성하기 위해 처리되는 INF 파일의 전체 경로 및 이름이다. INF의 처리는, 서버가 INF 파일에 접근할 수 없을 때(예를 들어, INF 파일이 CD 상에 있고 그 CD 판독기가 클라이언트 기기 상에서 분산 공유(share out)되지 않는 경우) 발생하는 문제를 피하기 위해 클라이언트 측에서 수행된다. INF 파일이 파싱되고 참조된 모든 파일들의 목록이 준비된다. 각각의 파일은 전체 경로와 함께 목록에서 제시된다. 이 목록은 서버로 전송되고 이에 대응하는 파일들이 그 서버에서 업로딩된다. 서버 상에 패키지를 업로딩하기 위한 위치(location)는 아래와 같은 서버 상의 레지스트리 키(registry key)의 DriverStorageShareName 값을 판독함으로써 발견할 수 있다.

- 이것은, 예를 들어, 프린트 서버 관리자에 의해 사용자 인터페이스를 통해서 구성될 수 있다.

앞서 설명된 바와 같이, 각각의 패키지는 고유하게 라벨이 붙여진 서브디렉토리로 할당된다. 발명의 예시적인 실시예에서, 업로딩된 패키지에 대하여 GUID가 생성되고, 그 패키지 GUID가 사용되어 DriverStorageShareName의 하위에 디렉토리 이름을 생성한다. 그 디렉토리의 하위에 YYYYMMDD의 형태를 갖는 서브디렉토리가 생성된다. 여기서 YYYY, MM 및 DD는 패키지의 현재 버전의 연, 월 및 일을 나타낸다. 모든 패키지 파일들은 그 서브디렉토리 아래로 복사된다. 패키지 트리의 디렉토리 구조는 그 패키지의 INF 파일에 의해 제공되는 구조를 따른다.

dwFlags는 API의 행동을 수정하기 위한 메커니즘을 제공한다. 예를 들어, dwFlags의 값이 0x01과 같은 경우, 서버 상에 패키지가 이미 존재한다면 그 패키지는 업로딩이 되는 동안 덮어쓰기/치환(overwritten/replaced)될 것이다.

hEvent는 호출자(caller)에 의해 제공되는 이벤트 핸들러(event handler)이다. 업로딩 작업이 끝나면 이에 대응하는 이벤트가 시그널링된다(signaled). hEvent가 NULL이면 그 호출은 동기(synchronous) 호출로 변환된다.

pError는 비동기 호출로부터 반환된 값이 기록되는 HRESULT에 대한 포인터(pointer)이다. 그 값은 hEvent가 시그널링된 후에 유효(valid)하게 될 것이다.

pdwCancelId는 (아래에서 기술된) UploadCancel API의 호출을 통해 비동기 UploadPrinterDriverPackage를 취소하도록 사용될 수 있는 DWORD 값에 대한 포인터이다. pdwCancelId의 값은 UploadPrinterDriverPackage가 반환된 직후에 유효하다.

pPackageId는 아래의 타입의 PackageId 구조에 대한 포인터이다.

비동기 호출이 완료되면, 그 호출이 지시하는 구조는 패키지의 GUID 및 시간을 포함하게 될 것이다. 수신된 DRIVER_PACKAGE_ID는 그 패키지의 서브디렉토리에 라벨을 붙이기 위해 사용된다.

InstallDriverFromPackage() API(710)

InstallDriverFromPackage() API(710)은 설치된 패키지로부터 드라이버를 설치한다. 플래그 파라미터(flags parameter)는 설치할 드라이버의 타입(프린터 드라이버, 포트 모니터, 프린트 프로세서 등)을 규정한다. 이 설치 방법은 메타데이터 저장소(304) 및 매니페스트 정보(504)를 업데이트하여 새롭게 설치된 드라이버를 반영한다. 활성화된 드라이버 저장소(302)에서 아직 존재하지 않는 설치된 드라이버 컴포넌트들의 범위에서, 새로운 서브디렉토리들이 더해지고 새로운 컴포넌트들이 새로운 컴포넌트 컨테이너들로 저장된다. 이하는 InstallDriverFromPackage() API(710)의 예시적인 형태이다.

위에서 요약된 API에서,

PszServer는 서버의 이름을 특정한다. 로컬 패키지 저장소로부터 드라이버를 설치하기 위해 NULL 값이 사용된다. 발명의 일 실시예에서, 드라이버 패키지는 식별된 pszServer가 정의하는 기기 상에 UploadPrinterDriverPackage API(700)를 통해서 이전에 설치되었다는 점에 주목할 것이다.

PackageID는 그 패키지로부터 드라이버를 설치하기를 원하는, 설치된 패키지를 정의한다. PackageID에 대한 값은 UploadPrinterDriverPackage API(700)에 의해 반환된다.

PszModelName은 프린터 드라이버의 이름이다. 식별된 프린터 드라이버는 PackageID에 의해 정의되는 패키지 내에 존재해야 한다.

PszEnvironment는 드라이버가 설치될 환경이다. 발명의 일 실시예에서, 문자열 이름들(string names)이 사용된다. 그러한 문자열의 예는 ""Windows NT x86", "Windows NT IA64" 및 "Windows NT AMD64"를 포함한다.

DwVersion은 설치될 드라이버의 버전을 규정한다.

DwFlags는 API의 디폴트 동작에 커스텀화(customization)의 특정을 용이하게 한다.

예시적인 플래그들은 잘 알려진 AddPrinterDriver API 의 대응 부분(counterpart)으로부터 유도될 수 있고, 이하를 포함한다.

IDFP_STRICT_UPGRADE

IDFP_STRICT_DOWNGRADE

IDFP_COPY_ALL_FILES

IDFP_COPY_NEW_FILES

IDFP_DONT_COPY_FILES_TO_CLUSTER

IDFP_COPY_TO_ALL_SPOOLERS

IDFP_NO_UI

IDFP_INSTALL_WARNED_DRIVER

AddPrinterDriver의 몇몇 플래그는 InstallDriverFromPackage API(710)에서 대응된는 부분을 갖지 않는다. 이들은 다음과 같다.

APD_COPY_FROM_DIRECTORY - DRIVER_INFO_6 구조를 거치지 않기 때문에 이는 필요하지 않다.

APD_RETURN_BLOCKING_STATUS_CODE - 하위 레벨 클라이언트들이 이 함수를 호출하지 않기 때문에 이 API가 항상 블로킹 코드(blocking code)를 반환하는데 기인한 것이다.

APD_DONT_SET_CHECKPOINT - 서명되지 않은(unsigned) 드라이버의 설치가 시도될 때마다 이 API가 체크포인트(checkpoint)를 설정하기 때문이다.

발명의 일 실시예에서, 일련의 플래그는, INF로부터 어떤 컴포넌트들을 설치할 것인지에 대해 보다 큰 통제권(control)을 호출자에게 부여하는 플래그들을 포함한다. 이 플래그들은 다음과 같다.

IDFP_INSTALL_PRINTER_DRIVER

IDFP_INSTALL_LANG_MONITER

IDFP_INSTALL_PRINT_PROC

IDFP_INSTALL_ICM_PROFILE

IDFP_INSTALL_ASP_PAGES

서명되지 않은 드라이버들은 InstallDriverFromPackage API(710)에 의해 다음과 같이 처리된다.

- 설치가 원격적으로(remotely) 행해지는 경우, 그 설치는 실패한다.

- 사용자가 관리자가 아닌 경우, 그 설치는 실패한다.

- 사용자가 관리자인 경우, PnP가 서버-측/클라이언트-측 설치에서 하는 것과 유사한 방법으로, 사용자의 문맥 내에서 다시 설치가 시도된다.

GetDriverStorageRoot(720)

GetDriverStorageRoot(720) 함수는 서버가 드라이버 패키지 저장소(300)의 드라이버 패키지들을 저장하는 루트 위치를 찾기 위하여 호출된다. 이 패키지 저장 루트 위치는, 발명의 일 실시예에서 통상적으로 관리자에 의해 설정된다. GetDriverStorageRoot(720) 함수의 형태는, 예들 들어, 다음과 같다.

pszServer는 드라이버 패키지 저장소(300)가 상주하는 서버의 전체 이름이다. 서버가 클러스터인 경우에는, 이 전체 이름은 클러스터의 이름으로 시작된다.

ppDStorageRootBuffer는 드라이버 저장 루트에 대한 경로를 포함하는 버퍼의 주소가 기록될 포인터에 대한 포인터이다. 발명의 일 실시예에서, 그 경로는 영으 로 종료된다(zero terminated). 버퍼에 대한 메모리는 API에 의해서 할당된다. 호출자는 LocalFree API에 대한 호출을 통해서 버퍼를 비우는 책임을 진다.

GetPrinterPackageInfo(730)

GetPrinterPackageInfo(730) 함수는 클라이언트가 패키지 정보의 열거를 요청할 수 있게 한다. 다음은 GetPrinterPackageInfo(730) 함수의 예시적인 형태이다.

UploadCancel(740)

UploadCancel(740) 함수는 이전에 인보크된(invoked) UploadPrinterDriverPackage API(700)에 대한 비동기 호출을 취소한다. 다음은 UploadCancel(740) 함수의 예시적인 형태이다.

dwCancelId는 취소될 UploadPrinterDriverPackage API(700)에 대한 호출에 의해 반환되는 식별자이다. dwCancelId 파라미터의 유효 값은 양수(positive)이 다. UploadCancel(740) 함수는 비동기 호출이 취소될 수 있는 경우 S_OK를 반환한다. 이 경우에 UploadPrinterDriverPackage API(700)는 정정(clean up) 후 그에 대응하는 이벤트를 시그널링한다. 만약 비동기 API가 취소될 수 없거나 dwCancelId의 값이 유효하지 않다면, UploadCancel(740) 함수는 E_FAIL을 반환할 것이다.

IPrintSetup(750)

발명의 일 실시예에서, IPrintSetup(750) 인터페이스는, 예를 들어 스풀러 드라이버들(예컨대 Winspool.drv)로부터 제공된 단일 COM 인터페이스 내의 사용자들에게 모든 새로운 인터페이스들을 공개한다(expose). IPrintSetup(750) 인터페이스는 모든 새로운 함수들을 둘러싸는 래퍼(wrapper)이다.

OpenDriver()(760)

OpenDriver()(760) 함수는 각각의 드라이버에 대해 핸들을 설정한다. 다음은 OpenDriver()(760) 함수의 예시적인 형태이다. 처음에 데이터 구조들이 제시된 다. 그 후, 예시적인 방법의 포맷이 요약된다.

SetDriverData()(770)

SetDriverData()(770) 함수는 드라이버와 관련된 특정한 파라미터들의 설정을 용이하게 한다. 예시적인 SetDriverData()(770) 함수는 다음과 같은 형태를 갖 는다.

GetDriverData()(780)

GetDriverData()(780) 함수는 드라이버와 관련된 특정한 파라미터들을 검색할 수 있게 한다. 예시적인 GetDriverData()(780) 함수는 다음과 같은 형태를 갖는다.

CloseDriver()(790)

CloseDriver()(790) 함수는 이전에 열렸던 드라이버의 해제(release)를 가능하게 하고, 그것에 의해 그 드라이버가 설치된 특정한 클라이언트 상의 클라이언트를 비활성화한다(inactivate). 예시적인 CloseDriver()(790) 함수는 다음과 같은 형태를 갖는다.

도 8로 가면, 컴퓨터 시스템의 드라이버 패키지 저장소(300) 내로 패키지(예 컨대 프린터 드라이버 패키지)를 설치하기 위한 일련의 단계들이 요약된다. 이 드라이버 패키지 저장소(300)는 예를 들면, 도 4에서 일반적으로 도시된 형태의 논리적인 구조를 갖는다. 앞서 기술된 바와 같이, 패키지가 설치될 때는, 그 패키지의 선택된 일부분만이 설치되기보다는 전체 패키지가 특정한 패키지 컨테이너 상에 설치된다. 처음에, 단계(800)에서 드라이버 패키지 저장소(300)를 유지하는 컴퓨터 시스템은 그 드라이버 패키지 저장소(300)로 완전한 타깃 패키지를 설치하기 위한 호출(예컨대 UploadPrinterDriverPackage(700))을 수신한다. 이에 응답하여, 단계(810)에서 설치자(installer)는 설치될 패키지로부터 식별 정보(distinguishing information)를 추출한다. 발명의 일 실시예에서, 설치자는 단계(810)에서 드라이버 패키지 저장소(300) 내로 설치될 패키지 내의 INF 파일로부터 패키지GUID 및 버전을 판독한다.

그 다음에, 단계(820)에서 설치자는 드라이버 패키지 컨테이너(450)에 접근하고, 드라이버 패키지 컨테이너(450) 내의 패키지 GUID 컨테이너들의 이름들 중 하나로서, 단계(810)에서 추출된 패키지GUID가 존재하는지 여부를 확인한다. 추출된 패키지GUID가 존재하지 않는 경우에는, 새로운 패키지 GUID 컨테이너가 생성되고 추출된 패키지GUID를 할당받는 단계(830)로 넘어가도록 제어된다. 따라서, 발명의 예시적인 실시예에서, 패키지 GUID 컨테이너는 동일한 패키지GUID를 갖는 모든 패키지 버전들을 유지한다. 그 후 단계(840)로 가도록 제어된다.

단계(840)에서, 드라이버 패키지의 특정한 버전을 유지하기 위해서 버전 컨테이너가 생성된다. 발명의 일 실시예에서 버전 컨테이너는 단계(810)에서 추출된 버전에 따라 라벨이 붙여진다. 예를 들어, 버전은 드라이버 패키지로 할당된 날짜이거나, 주요 릴리즈(major release), 서브-릴리즈, 및 버그수정 릴리즈들을 나타내는 복수의 연결된 문자와 숫자 값(concatenated alphanumeric value)을 포함하는 정식적인 버전 이름이다. 특정한 실시예에서, 버전은 4바이트의 입도(granularity)를 포함한다.

패키지를 유지하기 위한 새로운 버전 컨테이너를 생성한 뒤, 단계(850)에서 패키지는 새로운 버전 컨테이너 내로 저장된다. 저장된 패키지의 형태는 발명의 대안적인 실시예들에 따라 달라진다. 한편, 특정한 실시예에서, 단계(850)에서 설치된 원래(raw) 패키지의 CAB 파일들로부터 드라이버 파일들이 추출된다. 적어도 몇몇 예들에서 그러한 드라이버 파일들의 추출은 그 파일들을 압축 해제하는 것을 포함한다. 설치된 패키지에 대한 INF 파일에 의해 정의되는 어셈블리들에 따라, 컨테이너/서브디렉토리들이 생성된다. 이들은 제1 레벨에서 모델-및-제공자 GUID(MPG)에 의해 결정되고 그 다음의 제2 레벨에서 버전에 의해 결정되는 파일 시스템 위치(예컨대 서브-디렉토리들)에 추출된 드라이버들을 저장한다. 버전은, 패키지 버전들을 저장한 것과 유사한 방식으로, 예를 들어, 날짜 또는 문자들의 분할된 시퀀스에 의해 지시된다. 대안적으로, 드라이버들은 강력한 이름에 의해 식별된 컨테이너들에 저장된다.

도 8의 단계(860)에서 나타난 바와 같이 드라이버 패키지 저장소(300)의 디렉토리 구조에 파일들을 저장하고 난 후, 저장된 패키지들을, 그들의 드라이버들까지 포함하여, 기술하는 메타데이터가 메타데이터 저장소(304) 데이터베이스에 추가 된다. 그러한 데이터베이스의 유지는 중앙 드라이버 저장소(300)의 파일 내용들을 상대적으로 보다 빠르게 검색할 수 있게 한다. 단계(860)는 이전의 특정한 단계들에 실제로 의존하지 않고, 따라서 드라이버 패키지의 설치와 관련해 어느 때라도 행해질 수 있다는 점에 주목할 것이다. 그러나 드라이버 패키지 저장소(300) 상에 패키지가 실제로 설치될 때까지 기다림으로써, 메타데이터 저장소의 내용의 정확도가 보장된다. 그 후 끝 단계로 가도록 제어된다.

단계(820)로 돌아가서, 드라이버 패키지 컨테이너(450)에서 추출된 패키지GUID가 식별되면(기존의 패키지 GUID 컨테이너 하나와 일치하는 것으로 나타나면), 단계(870)로 가도록 제어된다. 단계(870)에서 패키지 버전(강력한 이름)이 기존의 패키지 버전들과 비교된다. 추출된 패키지 버전이 패키지 GUID 컨테이너 내에서 식별된 패키지 버전과 일치하지 않는 경우에는, 식별된 패키지의 이 특정한 버전은 드라이버 패키지 저장소(300)에 아직 존재하지 않는 것이고, 단계(840)로 가도록 제어된다. 한편, 단계(870)에서, 추출된 패키지 버전이 패키지 GUID 컨테이너 내에서 식별된 패키지 버전과 일치하는 경우에는, 패키지의 이 특정한 버전은 드라이버 패키지 저장소(300)에 이미 존재하고 있고, 단계(880)로 가도록 제어된다.

단계(880)에서, 설치자는 드라이버의 현재의, 동일할 수 있는 버전을 덮어쓸지 여부에 대한 선택권을 갖는다. 덮어쓰기를 바라는 경우에는, 단계(850)로 가도록 제어되고 패키지의 기존의 버전은 그와 일치하는 패키지 버전 컨테이너 라벨 하에서 교체된다. 덮어쓰기를 바라지 않는 경우에는, 끝 단계로 가도록 제어된다.

마지막으로, 앞서 기술된 패키지 설치 방법은, 패키지의 버전들 및 그 패키지 내의 드라이버들의 버전들 사이의 구별을 용이하게 하는 방식으로 패키지를 저장하기 위한 예시적인 프로세스라는 점을 유념할 것이다.

도 9로 가면, 네트워크 주변장치에 대하여 호환성 있는 드라이버를 설정하는 일련의 단계가 클라이언트 및 서버에 대하여 요약되어 있다. 예시적인 단계들을 통해, 클라이언트는 드라이버의 상이한 버전들이 따로따로 유지보수되도록 하는 방법으로, 드라이버를 드라이버 패키지 저장소(300)로부터 클라이언트 컴퓨터 시스템의 활성화된 드라이버 저장소(302)로 설치한다. 각각의 드라이버 버전은 활성화된 드라이버 저장소(302)에 저장되는 고유하게 식별되는 컴포넌트들(예컨대 매니페스트)의 목록과 연관된다. 매니페스트는 각각의 고유하게 식별된 컴포넌트에 대하여 활성화된 드라이버 저장소(302)에 저장된다. 또한, 각각의 드라이버 매니페스트/목록은, 클라이언트 상에서 유지되는 메타데이터 저장소(304)의 PhysicalDrivers 테이블(650)의, 특정한 드라이버 버전에 대응하는 엔트리 내에 저장된다.

동일한 이름을 갖는 상이한 파일들을 포함해, 동일한 드라이버의 복수의, 개별적인 버전들을 동시에 지원하기 위한 여러 방법들이 고려된다. 발명의 일 실시예에서, 그러한 분리는 각각의 활성화된 드라이버 버전의 모든 컴포넌트/파일들을, 고유하게 식별되는 파일 시스템 컨테이너(예컨대 서브디렉토리)에 저장함으로써 달성된다. 그러나 특정한 드라이버 컴포넌트(예컨대 유니드라이버(unidriver))는 많은 드라이버에 의해 사용되고, 각각의 드라이버/버전 결합에 대한 사본을 유지하는 것은 메모리 공간의 낭비가 될 수 있다. 따라서, 발명의 다른 실시예에서는 특정 한 드라이버에 대한 일련의 완전한 파일들보다 적은 양의 파일들을 고유하게 식별되는 파일 시스템 컨테이너에 저장한다. 대신, 완전한 드라이버가 활성화된 드라이버 저장소(302)의 복수의 서브디렉토리들 내에 저장된 컴포넌트들로부터 생성된다. 완전한 드라이버는 메타데이터 저장소(304) 내의 그 드라이버에 대한 매니페스트의 내용을 기반으로 하여 구축된다.

특정한 서브디렉토리의 파일/컴포넌트들의 통합 정리(consolidation)의 수준은 발명의 다양한 실시예들에 따라 달라진다. 일 실시예에서, 하나 이상의 파일들을 포함하는 각각의 컴포넌트 버전은 활성화된 드라이버 저장소(302)의 서브디렉토리로 할당된다. 또 다른 실시예에서, 고유하게 식별되는 서브디렉토리가 각각의 드라이버 버전에 대하여 설정되고, 그 서브디렉토리는 그 특정한 드라이버 버전과 관련된 공유되지 않는 컴포넌트/파일들을 포함한다. 드라이버 버전의 공유되는 컴포넌트들은 활성화된 드라이버 저장소(302)의 다른 위치에 포함된다.

발명의 특정한 실시예에서, 드라이버 파일들을 포함하는 서브-디렉토리들은, 애플리케이션 소프트웨어를 포함하는, 관련된 소프트웨어 모듈들의 그룹을 저장하는 일반화된 디렉토리 하에 저장된다. 각각의 서브-디렉토리에 할당된 고유 식별자 명칭(예컨대 강력한 이름)은 그 후, 매니페스트 정보(504)에 저장되는 컴포넌트 매니페스트 또는 특정한 드라이버 버전에 대한 메타데이터 저장소(304) 매니페스트를 통해, 특정한 드라이버 버전에 대하여 드라이버 파일들에 의존하는 클라이언트 소프트웨어로 제공된다. 또한, 발명의 일 실시예에서, 드라이버 파일들의 다양한 그룹을 포함하는 서브-디렉토리들은 다른 기기들이 클라이언트 기기로부터 드라이 버들을 판독하고 다운로드할 수 있도록 만들어지고, 따라서 "분산 공유(shared out)" 디렉토리로 불린다. (네트워크 프린터 드라이버에 대하여) 아래에서 기술되는 일련의 단계들은 클라이언트 및 그 클라이언트가 연결을 설정하려고 하는 서버가 모두 앞서 기술한 패키지 및 드라이버 버전을 구별하는 능력을 지원한다고 가정한다.

단계(900)에서 클라이언트 기기는 프린트 서버로 특정한 장치 드라이버의 식별을 위한 요청을 한다. 이 요청은, 예를 들어, GetPrinterDriver 또는 GetDriverData 호출이다. 그 후, 단계(910)에서 프린트 서버는 요청을 한 클라이언트로, 드라이버 패키지 저장소(300)가 유지하는 드라이버 파일 시스템 구조 내의 특정한 드라이버 버전의 위치를 알아내기에 충분한 드라이버 식별 정보를 반환한다. 발명의 특정한 실시예에서, 프린트 서버는 패키지GUID 및 버전과, 드라이버 MPG 및 버전을 반환한다. 발명의 예시적인 실시예에서, 이 정보는 메타데이터 저장소(304), 활성화된 드라이버 저장소(302) 또는 드라이버 패키지 저장소(300) 파일 시스템 내의 드라이버 버전을 명시하기에 충분하다. 또한 MPG 및 버전은, 요청을 하는 클라이언트가, (드라이버 버전 및 관련된 매니페스트를 역시 포함하는) 메타데이터 저장소(304) 또는 활성화된 드라이버 저장소(302)에 접근함으로써, 필요한 프린트 드라이버가 클라이언트 기기의 활성화된 드라이버 저장소(302)에 이미 존재하는지 여부를 확인할 수 있게 하는데 충분하다.

식별 정보를 수신하자마자, 단계(920)에서 클라이언트 기기는 식별된 드라이버 버전(예컨대 MPG 및 버전)이 그의 활성화된 드라이버 저장소(302)에 이미 존재 하는지 여부를 확인한다. 서버의 응답 내의 식별된 드라이버 버전이 클라이언트의 활성화된 드라이버 저장소(302) 내에 존재하는 경우, 클라이언트는 서버와 충분히 호환 가능한 상호 작용을 수행하는데 필요한 드라이버 컴포넌트들을 갖고 있는 것이고, 따라서 끝 단계로 가도록 제어된다. 한편, 식별된 드라이버가 존재하지 않는 경우, 단계(920)에서 단계(930)로 가도록 제어되고, 단계(930)에서 클라이언트 기기는 식별된 패키지GUID 및 버전이 공지의 위치(로컬 위치 또는 중앙 드라이버 저장소(212)와 같이 다른 기기 상에서 분산 공유되는 몇몇 공지의 위치)에서 이용 가능한지 여부를 확인한다. 식별된 패키지GUID 및 버전이 클라이언트가 이용 가능한 패키지와 대응되지 않는 경우에는 단계(940)로 가도록 제어된다.

단계(940)에서, 클라이언트 기기는 네트워크에서 식별된 패키지 및 버전의 위치를 결정한다. 발명의 예시적인 실시예에서, 클라이언트 기기는 드라이버 패키지 저장소(300)로 요청을 보낸다. 드라이버 패키지 저장소(300)는, 예를 들어, 모든 드라이버 패키지들 및 (공유 이름(share name)에 의해 식별되는) 그들 각각의 위치들의 목록을 유지하는 프린트 서버 (또는 중앙 드라이버 저장소(212)) 상의 서비스에 의해 제공된다. 따라서, 단계(940)에서, 드라이버 패키지 저장소(300)는, 예를 들어, 단계(910)에서 식별된 패키지 버전의 사본을 요청하기 위해 클라이언트에 의해 사용되는, "＼＼서버＼공유 이름(＼＼server＼share name)"을 반환한다. 본 발명은 드라이버 버전보다는 패키지 버전의 식별을 이용한다는 점에 주목할 것이다. 그러나 드라이버 버전들이 분산 공유되는 발명의 대안적인 실시예에서, 클라이언트들은 특정한 드라이버 버전에 대한 위치를 요청할 수 있다. 요청한 네트 워크 위치를 수신하자마자, 단계(950)로 가도록 제어된다.

단계(950)에서, 클라이언트는 패키지 (또는 대안적으로 드라이버) 버전의 공지된 위치로부터 식별된 패키지 버전을 업로딩할 것을 요청한다. 업로딩 요청은, 예를 들어, 서버 이름, 공유 이름, 패키지GUID 및 버전을 포함한다. 요청한 드라이버 패키지 버전을 수신하자마자 클라이언트 기기는 그의 로컬 드라이버 패키지 저장소(300) 내로 그 패키지를 설치한다. 이러한 설치는, 예를 들어, 도 8을 참조하여 기술된 단계들을 따른다. 그 후 단계(960)로 가도록 제어된다.

단계(960)에서, 클라이언트 기기는 메소드/함수를 인보크하여, 단계(910)에서 식별된 드라이버 버전을 패키지 저장소(300)로부터 활성화된 드라이버 저장소(302)로 설치한다. 단계(960)에서, 설치된 드라이버 버전의 컴포넌트들을 저장하기 위해 활성화된 드라이버 저장소(302) 내에 하나 이상의 새로운 서브-디렉토리 컨테이너들이 생성되고, 이 새로운 서브디렉토리들은 고유 식별자 명칭(예컨대 MPG 및 버전)을 제공받으며, 단계(910)에서 식별된 드라이버 버전의 드라이버/컴포넌트 버전들에 대응하는 드라이버 파일들은 패키지로부터 새로운 서브디렉토리들로 복사된다. 그 후, 단계(970)로 가도록 제어되며, 이 단계(970)에서, 활성화된 드라이버 저장소(302)의 매니페스트 정보(504)는 새롭게 설치된 드라이버 버전(이 버전을 구성하는 컴포넌트들을 목록화하는 드라이버 매니페스트를 저장하는 새로운 파일 포함)과 관련된 새로운 매니페스트들을 포함하기 위하여 업데이트된다. 그리고, 발명의 일 실시예에서, 새로운 활성화된 드라이버에 대응하는 메타데이터 저장소(304) 내에 새로운 엔트리가 생성된다. 새로운 엔트리/매니페스트 정보는 고유 식별자 명칭과 함께, 드라이버 매니페스트 목록 및 새롭게 설치된 드라이버 버전을 구성하는 (활성화된 드라이버 저장소(302) 내의) 컴포넌트들을 포함한다. 새로운 매니페스트 정보/드라이버 엔트리를, 예를 들어, 각각의 새로운 드라이버 버전에 대한 메타데이터 저장소(304) 내에 생성함으로써, 그리고 드라이버 컴포넌트/파일들의 상이한 버전들을 고유하게 식별되는 서브디렉토리들 내에 저장함으로써, 앞서 기술된 방법은 동일한 이름을 가지나 상이한 내용을 포함하는 드라이버 파일들(예컨대 동일한 드라이버 파일의 버전들)을 덮어쓰는 것을 방지한다. 그 후 단계(970)에서 끝 단계로 가도록 제어된다.

단계(930)로 돌아가, 만약 클라이언트가 식별된 패키지를 (로컬 영역에서 또는 공지의 파일 공유 상에서) 이용할 수 있다면, 단계(980)로 가도록 제어된다. 단계(980)에서, 패키지 버전이 로컬 영역에 저장되지 않은 경우, 앞서 기술된 단계(950)로 가도록 제어된다. 반면, 패키지가 로컬 영역에서 이용 가능한 경우, 단계(960)로 가도록 제어되고, 단계(910)에서 식별된 드라이버 버전은 클라이언트의 활성화된 드라이버 저장소(302)에 설치된다.

드라이버 버전들이 어떻게 식별되고 활성화된 드라이버 저장소(302)에 저장되는 지가 앞에서 설명되었고, 도 10에서는 프린트 클라이언트가, 그 클라이언트의 활성화된 드라이버 저장소(302)에 현재 저장되는 공지의 드라이버 버전을 사용하여 동작하는 특정한 프린트 서버와 상호 작용하기 위해, 활성화된 드라이버 저장소(302)로부터의 특정한 드라이버 버전에 접근하는 일련의 단계들이 요약된다.

처음에, 단계(1000)에서, 클라이언트 애플리케이션은, 예를 들어, 특정한 프 린트 서버에 의해 지원되는 프린터에 대한 프린트 대기열(print queue)과 같은, 서비스 객체의 사용을 요청한다. 프린트 대기열에 대하여, 그러한 요청은 그 프린트 대기열에 의해 좌우되는 (프린터의) 프린트 가능한 영역에 대한 것일 수 있고, 이러한 종류의 데이터는 프린트 드라이버로부터 래퍼 계층(wrapper layer)을 통해 제공된다. 이 래퍼 계층은 운영 체계 및 그 API의 일부이다. 그러한 요청은, 예를 들어, 워드 프로세싱 애플리케이션에 의한 프린트 요청에 의해 시작된다. 그 후, 단계(1010)에서, 운영체계는 특정한 프린트 대기열에 대해 필요한 정확한 드라이버 버전을 검색한다 (이것은 현재의 대기열과 관련된 프린트 서버에 의해 현재 사용되고 있는 드라이버 버전이다). 이는 대기열에 대해 필요한 프린트 드라이버들을 결정하는 다수의 공지된 방법들에 의해 달성될 수 있다. 예시적인 실시예는 드라이버 그 자체를 일반적으로 식별하는 것 외에도, 그 드라이버의 버전을 확인함으로써 종래의 공지 버전들을 증축한다.

그 다음에, 단계(1020)에서, 프린트 시스템은 특정한 드라이버 버전을 실행하기 위한 활성화 문맥(activation context)을 드라이버의 매니페스트로부터 생성한다. 이 활성화 문맥은, 운영체계를 위하여, 고유하게 식별되는 드라이버 버전에 따라 그 드라이버 컴포넌트 버전들에 접근하기 위한 검색 경로를 제공한다. 이 문맥은 식별된 드라이버 버전의 컴포넌트들을 검색해내기 위한 위치들의 순서를 지시한다. 따라서, (이 예에서는 운영체계의 프린트 서브시스템인) 애플리케이션이 버전을 특정하지 않은 채 Unidrv를 요청하는 경우 (다르게 말하면, 강력한 이름을 특정하지 않고, 그 일부만인 경우), 활성화 문맥은 특정한 버전을 로딩할 수 있게 하 는 정보를 제공한다. 문맥의 제공은, 단순히 그 문맥이 유도된 드라이버 매니페스트를 교환함으로써, 애플리케이션을 하나의 드라이버 컴포넌트로부터 다른 것(예컨대 공유된 컴포넌트의 업데이트된 버전)으로 교환할 수 있게 한다. 따라서, 요약하면, 문맥을 활성화하는 것은 특정한 드라이버 버전과 관련된 특정한 검색 경로를 활성화하는 것에 대응한다.

활성화 문맥을 생성한 후, 단계(1030)에서, 시스템은 활성화 문맥에 기반한 특정한 드라이버 버전과 관련된 드라이버 컴포넌트들을 로딩하고, 그 뒤에 특정한 드라이버 버전과 관련된 명령/동작을 수행하기 위해 그 드라이버를 호출(call into)한다.

그 다음에, 단계(1040)에서, 드라이버는 부가적인 파일들(예컨대, 구성 파일들, 헬퍼 DLL들)을 로딩할 수 있다. 그렇게 하는 경우, 드라이버는 드라이버 매니페스트에서 명시된 위치/경로에 따라 그 컴포넌트들(파일들)의 버전들을 획득한다. 발명의 일 실시예에서, 드라이버의 컴포넌트는 또한 부가적인 드라이버 파일/컴포넌트들을 정의하는 매니페스트를 포함할 수 있다. 이러한 부가적인 파일들은 또한, 클라이언트 기기 상에서 실행될 특정한 드라이버 버전이 서버 기기 상의 버전과 일치될 수 있게 하는 GUID뿐 아니라, 버전 정보에 의해서도 식별된다. 버전들은 (드라이버 및 그의 컴포넌트들의 매니페스트에 의해 좌우되는) 현재 활성화된 문맥에 의해 지배된다.

마지막으로, 단계(1050)에서, 드라이버로 보내진 요청을 완수한 후, 프린트 시스템은 문맥을 비활성화(deactivate)하고, 단계는 '끝'으로 가도록 제어된다. 현 실시예가 네트워크 프린트 드라이버를 참조하여 주어졌지만, 본 발명이 팩스 기기, 스캐너 등의 다른 공유 네트워크 주변장치에도 적용될 수 있다는 점을 유념할 것이다.

당업자는 네트워크 주변장치 환경에서 주변장치 드라이버들 및 그들의 구성 컴포넌트들을 유지보수하기 위한 새롭고 유용한 방법 및 시스템이 설명되었음을 이해할 것이다. 본 발명의 원리가 적용될 수 있는 많은 가능한 환경들의 관점 및 소프트웨어 유틸리티 및 툴들의 고안 및 실행의 유연성의 관점에서 볼 때, 본 명세서에서 설명된 실시예들은 예시적인 것으로 의도되고, 발명의 범위를 제한하는 것으로 받아들여져서는 안 된다는 점을 인식해야 한다. 본 발명이 적용되는 당업자는 예시적인 실시예들이 본 발명의 기술 사상에서 벗어나지 않고도 그 배열 및 세부항목에 있어서 수정될 수 있다는 점을 이해할 것이다. 따라서, 본 명세서에서 설명된 바와 같은 발명은, 이어지는 특허청구범위 및 그의 균등 범위 내에 존속할 수 있는 모든 실시예들을 고려한다.

본 발명은 네트워크 주변장치 환경의 기기들 상에서 드라이버들의 잠재적으로 상이한 버전들 및 이들과 관련된 컴포넌트 버전들을 유지보수하는 것에 관한 종래 기술의 여러 단점들을 바로잡기 위해 노력한다.

개시된 새로운 방법 및 시스템에 의해 네트워크 주변장치 환경에서 주변장치 드라이버들 및 그들의 구성 컴포넌트들을 유지보수할 수 있다. 특히 이 방법은, 예를 들어, 동시에 활성화된 네트워크 주변장치 드라이버들 중에서 상이한 드라이 버들이 동일한 이름을 갖는 상이한 컴포넌트들 및/또는 파일들을 포함하는 경우에도 모든 네트워크 주변장치/서버들과의 호환성을 보장한다.

Claims

네트워크 기기 상에서, 동시에 활성화된 복수의 네트워크 주변장치 드라이버들(multiple simultaneously active netwoked peripheral device drivers)의 컴포넌트들을 유지보수(maintaining)하기 위한 방법 - 상기 동시에 활성화된 네트워크 주변장치 드라이버들의 상이한 컴포넌트들은 동일한 이름을 갖는 상이한 주변장치 드라이버 파일들을 잠재적으로 포함함 - 으로서, 상기 네트워크 기기에 의해 수행되는 상기 방법은,

네트워크 주변장치에 대한 주변장치 대기열(queue)에 대한 드라이버 식별 정보를 요청하는 단계 - 상기 드라이버 식별 정보는 서버에 의해 유지됨- ;

상기 요청하는 단계에 대한 응답으로, 네트워크 주변장치 드라이버의 특정한 버전, 패키지 버전, 및 특정한 드라이버 패키지를 명시하는 드라이버 식별 부호(driver identification)를 수신하는 단계 - 상기 버전은 인코딩된 멀티-세그먼트 값(multi-segmented value)을 포함함 - ;

상기 드라이버 식별 부호를 상기 네트워크 기기에 의해 현재 유지되는 활성화된 드라이버 패키지들, 활성화된 드라이버 버전들, 및 활성화된 드라이버 패키지들의 패키지 버전들의 세트와 비교하는 단계;

장치 드라이버들의 세트가 상기 드라이버 식별 부호에 대응하는 드라이버 패키지, 패키지 버전, 및 드라이버 버전을 포함하지 않음을 확인하는 단계;

드라이버 패키지 식별 부호를 포함하는 쿼리를 장치 드라이버 컴포넌트들의 리포지토리(repository)로 발행하는 단계;

상기 장치 드라이버 컴포넌트들의 리포지토리로부터 상기 네트워크 주변장치 드라이버의 특정 패키지, 특정 패키지 버전, 및 특정 버전에 대응하는 장치 드라이버 파일들의 완전한 세트의 사본을 획득하는 단계;

활성화된 네트워크 주변장치 드라이버 컴포넌트들에 대한 컨테이너들을 유지하는 활성화된 드라이버 컴포넌트 저장 장치(storage)를 제공하는 단계;

네트워크 주변장치 드라이버 컴포넌트의 버전, 패키지 버전, 및 패키지를 구성하는 상기 장치 드라이버 파일들의 세트를 저장하기 위한 컨테이너를 설정하는 단계 - 상기 컨테이너는 상기 네트워크 기기의 상기 활성화된 장치 드라이버 컴포넌트들과 연관됨 - ;

상기 컨테이너에 고유 식별자 명칭(unique identifier name)을 할당하는 단계 - 상기 고유 식별자 명칭은 상기 장치 드라이버 컴포넌트의 패키지 식별 부호 및 버전 식별 부호를 포함함 - ; 및

상기 컨테이너 내에 상기 장치 드라이버 파일들의 세트를 삽입하는 단계

를 포함하는, 복수의 네트워크 주변장치 드라이버들의 컴포넌트들을 유지보수하기 위한 방법.
제1항에 있어서, 상기 컨테이너는 파일 시스템 서브-디렉토리인, 복수의 네트워크 주변장치 드라이버들의 컴포넌트들을 유지보수하기 위한 방법.
제1항에 있어서, 상기 버전은 날짜를 포함하는, 복수의 네트워크 주변장치 드라이버들의 컴포넌트들을 유지보수하기 위한 방법.
네트워크 기기 상에서, 동시에 활성화된 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 시스템 - 상기 동시에 활성화된 네트워크 주변장치 드라이버들 중 상이한 드라이버들은 동일한 이름을 갖는 상이한 주변장치 드라이버 파일들을 잠재적으로 포함함 - 으로서,

적어도 하나의 메모리;

적어도 하나의 프로세서;

네트워크 주변장치에 대한 서버에 의해 유지되는 주변장치 대기열(queue)에 대한 드라이버 식별 정보를 요청하기 위한 수단;

상기 요청하기 위한 수단에 대한 응답으로, 네트워크 주변장치 드라이버의 특정한 버전, 특정한 패키지, 및 패키지 버전을 명시하는 드라이버 식별 부호(driver identification)를 수신하기 위한 수단 - 상기 버전은 인코딩된 멀티-세그먼트 값(multi-segmented value)을 포함함 - ;

상기 드라이버 식별 부호를, 상기 네트워크 기기에 의한 사용을 위하여 현재 유지되는 활성화된 드라이버 패키지들, 패키지 버전들, 및 드라이버 버전들의 세트와 비교하기 위한 수단;

상기 드라이버 패키지들, 패키지 버전들, 및 드라이버 버전들의 세트가 상기 드라이버 식별 부호에 대응하는 드라이버 패키지, 패키지 버전, 및 드라이버 버전을 포함하지 않음을 확인하기 위한 수단;

드라이버 패키지 식별 부호를 포함하는 쿼리(query)를 주변장치 드라이버 컴포넌트들 및 드라이버 패키지들의 네트워크 디렉토리로 발행하기 위한 수단;

상기 주변장치 드라이버 컴포넌트들 및 드라이버 패키지들의 네트워크 디렉토리로부터 상기 드라이버 식별 부호의 드라이버 패키지, 패키지 버전, 및 드라이버 버전에 대응하는 장치 드라이버 파일들의 세트의 사본을 획득하기 위한 수단;

상기 활성화된 네트워크 주변장치 드라이버 컴포넌트들에 대한 컨테이너들을 유지하는 활성화된 드라이버 컴포넌트 저장 장치를 제공하기 위한 수단;

네트워크 주변장치 드라이버 컴포넌트의 버전, 패키지 버전, 및 패키지를 구성하는 상기 장치 드라이버 파일들의 세트를 저장하기 위한 컨테이너를 설정하기 위한 수단 - 상기 컨테이너는 상기 네트워크 기기의 상기 활성화된 장치 드라이버 컴포넌트들과 연관됨 - ;

상기 컨테이너에 고유 식별자 명칭(unique identifier name)을 할당하기 위한 수단 - 상기 고유 식별자 명칭은 상기 장치 드라이버 컴포넌트의 패키지 식별 부호 및 버전 식별 부호를 포함함 - ; 및

상기 컨테이너 내에 상기 장치 드라이버 파일들의 세트를 저장하기 위한 수단

을 포함하는, 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 시스템.
제4항에 있어서, 상기 컨테이너는 파일 시스템 서브-디렉토리인, 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 시스템.
제4항에 있어서, 상기 버전은 날짜를 포함하는, 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 시스템.
제4항에 있어서, 상기 획득하기 위한 수단은 상기 드라이버 버전의 사본을 포함하는 드라이버 패키지 버전의 완전한 사본을 획득하는, 복수의 네트워크 주변장치 드라이버들을 유지보수하기 위한 시스템.
컴퓨터에 의한 실행시 상기 컴퓨터로 하여금, 네트워크 기기 상에서, 동시에 활성화된 복수의 네트워크 주변장치 드라이버들의 컴포넌트들의 유지보수를 용이하게 하는 방법을 수행하도록 하는 명령어들을 포함하는 컴퓨터 판독가능 기록 매체 - 상기 동시에 활성화된 네트워크 주변장치 드라이버들의 상이한 컴포넌트들은 동일한 이름을 갖는 상이한 주변장치 드라이버 파일들을 잠재적으로 포함함 - 에 있어서, 상기 네트워크 기기에 의해 수행되는 상기 방법은,

네트워크 주변장치에 대하여 유지된 주변장치 대기열에 대한 드라이버 식별 정보를 요청하는 단계 - 상기 드라이버 식별 정보는 서버에 의해 유지됨- ;

상기 요청하는 단계에 대한 응답으로, 네트워크 주변장치 드라이버의 특정한 버전, 특정한 패키지 버전, 및 특정한 패키지를 명시하는 드라이버 식별 부호(driver identification)를 수신하는 단계 - 상기 버전은 인코딩된 멀티-세그먼트 값(multi-segmented value)을 포함함 - ;

상기 드라이버 식별 부호를 상기 네트워크 기기가 이용 가능한 네트워크 리포지토리에 현재 유지되는 활성화된 드라이버 패키지들, 패키지 버전들, 및 드라이버 버전들의 활성화된 세트와 비교하는 단계;

상기 드라이버 버전들의 세트가 상기 드라이버 식별 부호에 대응하는 드라이버 버전을 포함하지 않음을 확인하는 단계;

드라이버 패키지 식별 부호를 포함하는 쿼리를 네트워크 리포지토리로 발행하는 단계;

상기 네트워크 기기가 이용 가능한 활성화된 드라이버 패키지들, 활성화된 패키지 버전들, 및 드라이버 버전들의 활성화된 세트에 포함되어 있지 않은 드라이버 패키지, 패키지 버전, 및 드라이버 버전에 대응하는 장치 드라이버 파일들의 완전한 세트의 사본을 획득하는 단계;

활성화된 네트워크 주변장치 드라이버 컴포넌트들에 대한 컨테이너들을 유지하는 활성화된 드라이버 컴포넌트 저장 장치를 제공하는 단계;

네트워크 주변장치 드라이버 컴포넌트의 버전을 구성하는 장치 드라이버 파일들의 세트를 저장하기 위한 컨테이너를 설정하는 단계 - 상기 컨테이너는 상기 네트워크 기기의 활성화된 장치 드라이버 컴포넌트들과 연관됨 - ;

상기 컨테이너에 고유 식별자 명칭(unique identifier name)을 할당하는 단계 - 상기 고유 식별자 명칭은 상기 장치 드라이버 컴포넌트의 패키지 식별 부호 및 버전 식별 부호를 포함함 - ; 및

상기 컨테이너 내에 상기 장치 드라이버 파일들의 세트를 삽입하는 단계

를 포함하는, 컴퓨터 판독 가능 기록 매체.
제8항에 있어서, 상기 컨테이너는 파일 시스템 서브-디렉토리인 컴퓨터 판독가능 기록 매체.
제8항에 있어서, 상기 버전은 날짜를 포함하는 컴퓨터 판독가능 기록 매체.
제8항에 있어서, 상기 획득하는 단계는 상기 드라이버 버전의 사본을 포함하는 드라이버 패키지 버전의 완전한 사본을 획득하는 단계를 포함하는 컴퓨터 판독가능 기록 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제