KR101137146B1

KR101137146B1 - 설치에 대해 유효한 의존적 소프트웨어 갱신의 최대세트를 판정하는 시스템 및 방법

Info

Publication number: KR101137146B1
Application number: KR1020040107180A
Authority: KR
Inventors: 글라움제프리; 마클리마이클; 쉘스콧
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-12-16
Filing date: 2004-12-16
Publication date: 2012-04-19
Also published as: CN1645322A; CN1645322B; EP1548586A3; US20050132350A1; KR20050061376A; JP5025901B2; US7568195B2; EP1548586A2; EP1548586B1; JP2005182784A

Abstract

설명된 시스템 및 방법은 (예를 들면, 내장된 컴퓨팅 장치에) 설치하기 위한 일군의 소프트웨어 패키지가 그 의존 관계에 대해 검토되어, 패키지 의존도 제약을 고려하면서, 가능한 가장 적은 갱신 단계로 임의의 패키지에 대한 최대 버전 갱신을 허용하도록 설치 가능성의 최대 세트를 선택하는 것이 가능해진다. 갱신 검증 처리는 장치에 다운로드된 갱신 패키지를 조직화하고 검증하고, 각 그룹에 대한 그래프를 생성한다. 갱신간의 경로를 포함하는 그래프 데이터는 하나 이상의 경로가 동일한 버전을 얻기 위해 사용될 수 있을 때 최소 가중치(비용)로 원하는 갱신을 생성하기 위해서 장치상 기존 영상에 적용될 수 있는 패키지의 최소 최적 세트를 판정하기 위해 갱신을 검증하도록 처리된다.

소프트웨어, 패키지, 갱신, 의존도, 경로, 그래프, 가중치, 컴퓨팅 장치

Description

설치에 대해 유효한 의존적 소프트웨어 갱신의 최대 세트를 판정하는 시스템 및 방법{DETERMINING THE MAXIMAL SET OF DEPENDENT SOFTWARE UPDATES VALID FOR INSTALLATION}

도 1은 본 발명이 결합될 수 있는 컴퓨터 시스템을 전반적으로 나타내는 블럭도.

도 2는 본 발명의 일형태에 따른 패키지 의존도 정보를 얻기 위해 사용되는 메니페스트 파일을 나타내는 도면.

도 3a 및 3b는 본 발명의 일형태에 따른 의존도 정보 처리를 포함하는 갱신 검증 처리를 수행하기 위한 흐름도.

도 4는 본 발명의 일형태에 따른 갱신 검증 처리를 수행하는 다양한 메커니즘을 나타내는 블럭도.

도 5a 및 5b는 본 발명의 일형태에 따른 의존도 정보 처리를 포함하는 갱신 순서화 처리를 수행하기 위한 흐름도.

도 6은 본 발명의 일형태에 따른 패키지 의존도를 계산하기 위한 그래프를 구성하기 위한 흐름도.

도 7a 및 7b는 본 발명의 일형태에 따른 패키지 갱신 그래프의 이동을 수행하기 위한 흐름도.

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

120: 휴대용 컴퓨팅 장치

122: 처리기

124: 메모리

130: 운영 체계

132: 응용 프로그램

134: 통지 관리기

136: 망 소프트웨어

본 발명은 본 명세서에 그 전체가 결합된 2003년 12월 16일에 출원된 미국 가출원 제60/530,130호에 대한 우선권을 청구한다.

본 발명은 본 건과 동시에 출원되고 그 전체가 본 명세서에 결합된 이하의 미국 특허 출원과 연관된 것이다.

사건번호 제4271/307,649호 "고장 안심 방식으로 맞춤 소프트웨어 영상 갱신을 비휘발성 저장 장치에 적용하기(Applying Custom Software Image Updates to Non-Volatile Storage in a Failsafe Manner)".

사건번호 제4291/307,651호 "소프트웨어 갱신이 장치의 특수 장치 또는 클래스 상에서만 설치될 수 있고 실행될 수 있음을 보장하기(Ensuring that a Software Update may be Installed or Run only on a Specific Device or Class of Devices)".

사건번호 제4301/307,652호 "자체 설명 소프트웨어 영상 갱신 컴포넌트(Self-Describing Software Image Update Components)".

사건번호 제4311/307,663호 "저장 장치 기술 요약 방식으로 파일 내에 파일 시스템 생성하기(Creating File Systems Within a File in a Storage Technology-Abstracted Manner)".

본 발명은 일반적으로 내장된 운영 체계를 구비하는 것과 같은 컴퓨팅 장치에 관한 것으로서, 보다 구체적으로는 컴퓨팅 장치의 비휘발성 저장 장치를 갱신하는 시스템 및 방법에 관한 것이다.

개인용 디지털 기기, 최신 이동 전화, 휴대용 초소형 컴퓨터와 같은 이동 컴퓨팅 장치는 중요하고 인기있는 사용자 도구가 되고 있다. 일반적으로, 이들은 배터리 전력을 덜 소모하는 동시에 보다 강력한 응용 프로그램을 실행할 수 있으면서도 매우 편리하게 소형이 되고 있다.

이러한 장치를 제조하는 공정에서, 내장된 운영 체계 영상은 통상 단조증가성 영상 파일로 이루어지고, 각 장치의 비휘발성 저장 장치(예, NAND 또는 NOR 플래시 메모리, 하드디스크 등)에 저장된다. 결국, 전술한 이러한 장치의 갱신은 때때로 필요하거나 바람직하다.

그러나, 단조증가성 운영 체계는 다수의 불리함을 갖는데, 이는 갱신을 설치하기 위해서 많은 양의 자원(예를 들면, 임시 저장 장치 및 대역폭)이 전체 단조증 가성 영상을 대체하기 위해 필요하다는 점을 포함한다. 동시에, 장치의 기존 패키지 설치 상태가 가변적이고, 설치를 위해 큐잉된 임의의 수의 버전의 패키지가 있을 수 있기 때문에, 운영 체계의 일부 컴포넌트를 설치하는 것은 어려운 일이다. 현재, 무엇이 설치될 것인지 알기 위해 장치상 설치된 영상을 문의하는 공지된 지능적 영상 갱신 서버 기반시설은 없다. 이러한 서버 기반시설이 개발될 수 있다고 해도, 그러나, 장치의 설치 상태 정보를 서버와 공유하는데 있어 프라이버시 문제가 있을 것이다. 많은 갱신 버전 및 그 버전 사이의 충돌 및 의존도를 가지고 수행될 수 있는 장치측에서 장치 갱신을 처리하기 위한 효율적인 방법이 필요하다.

간단하게, 본 발명은 (예를 들면, 내장된 컴퓨팅 장치에) 설치하기 위한 일군의 소프트웨어 패키지가 그 의존 관계에 대해 검토되어, 패키지 의존도 제약을 고려하면서, 가능한 가장 적은 갱신 단계로 임의의 패키지에 대한 최대 버전 갱신을 허용하도록 설치 경우의 최대 세트를 선택하는 것이 가능해지는 시스템 및 방법을 소개한다. 이는 설치를 위해 큐잉된 버전이 다른 패키지는 물론 장치상 기존 패키지 설치 상태를 알게 되어 달성된다.

설치될 모든 패키지는 먼저 검증되는데, 이는 설치를 위해 큐잉된 패키지가 완벽성에 대해 검토되고, 콘텐츠가 검증되고, 갱신 권한이 판정되고(서명 메커니즘으로부터), 의존도 관계가 판정되는 처리를 지칭한다. 일구현예에서, 검증 처리의 결과는 검증 요구사항을 통과해서 설치될 수 있는 패키지의 목록과 검증 요구사항 중 하나 이상을 만족시키는데 실패하여 설치될 수 없는 패키지 및 실패 원인의 목 록인 두 개의 목록을 포함한다. 이 목록들은 설치 순서로 소팅된다.

갱신 검증기/검증 처리가 제공되어, 일반적으로 갱신되고 있는 목표 패키지에 기초하여 장치에 그룹으로 다운로드된 갱신 패키지의 세트를 조직화하고 검증한다. 각 그룹은 갱신을 생성하기 위해서 장치의 기존 영상에 적용될 수 있는 패키지의 최소 최적 세트를 판정하기 위해 처리된다. 패키지의 최소 최적 세트를 판정하기 위해서, 패키지는 기본 노드(목표 패키지를 나타냄)로부터 잎 노드 각각으로 다중 경로를 가질 수 있는 그래프로 조직화된다. 그래프는 패키지 세트에 걸쳐 최적의 경로 판정을 용이하게 하여, 기존 장치 패키지가 가장 낮은 비용(가중치) 갱신을 갖고 갱신 세트 내에 규정된 각 패키지의 최고 가능한 버전으로 갱신될 수 있다. 이를 위해, 그래프가 생성된 후, 하나 이상의 경로가 동일한 버전을 얻기 위해 사용될 수 있을 때, 최소의 가중치(비용)로 장치가 갱신될 수 있는 최고 버전을 찾기 위해 시도하면서, 다양한 검증 처리를 위해 사용된다.

일구현예에서, 검증 처리는, 예를 들면, 갱신 응용 프로그램이라 불리는 응용 프로그램 인터페이스로서 액세스 가능하다. 검증 처리는 각 패키지에 대한 장치 메니페스트 파일(장치 메니페스트 파일은 패키지를 설명함)을 탐색하고, 찾으면, 패키지는 패키지 그래프에 (예를 들면, 그 패키지를 위한 표현 노드로서) 추가된다. 각 메니페스트 파일이 처리되었을 때, 부모 노드의 증명 사슬을 점검하는 것과 유효하지 않을 때 부모 노드로부터 트리로부터의 모든 해당 브랜치를 절단하는 것을 포함하여 그래프 처리는 증명 정보를 구한다. 그래프의 브랜치 및 노드가 서명 검증을 포함하여 처리되었을 때, 가장 낮은 가중치의 브랜치가 판정되고, 그 브랜치는 호출 객체로 리턴될 갱신 목록에 추가된다.

다른 유리함은 이하 상세한 설명을 도면과 결합하여 이해하면 자명해질 것이다.

도 1은 처리기(122), 메모리(124), 표시기(126), 키보드(128)(물리적 또는 가상적 키보드 또는 모두를 나타냄)를 포함하여, 이러한 휴대용 컴퓨팅 장치(120)의 기능적 구성요소를 도시한다. 마이크로폰(129)은 오디오 입력을 수신하기 위해 마련될 수 있다. 메모리(124)는 일반적으로 휘발성 메모리(예, RAM) 및 비휘발성 메모리(예, ROM, PCMCIA 카드, 등) 모두를 포함한다. 마이크로소프트사의 윈도우즈 운영 체계 또는 다른 운영 체계와 같은 운영 체계(130)는 메모리(124)에 저장되고 처리기(122)에서 실행된다.

하나 이상의 응용 프로그램(132)은 메모리(124)에 로드되어 운영 체계(130)에서 실행한다. 응용 프르그램의 예는 이메일 프로그램, 스케줄링 프로그램, PIM(개인용 정보 관리) 프로그램, 문서 작성 프로그램, 스프레드쉬트 프로그램, 인터넷 브라우저 프로그램 등을 포함한다. 휴대용 개인용 컴퓨터(120)는 메모리(124)에 로드되고 처리기(122)에서 실행하는 통지 관리기(134)도 포함할 수 있다. 통지 관리기(134)는, 예를 들면, 응용 프로그램(132)으로부터의 통지 요청을 처리한다. 또한, 이하 설명하는 것처럼, 휴대용 개인용 컴퓨터(120)는 전화 호를 이루는 것을 포함할 수 있는 휴대용 개인용 컴퓨터(120)를 망에 연결하는데 적절한 망 소프트웨어(136)(예, 하드웨어 드라이버 등) 및 망 구성요소(138)(예, 라디오 및 안테나)를 포함한다.

휴대용 개인용 컴퓨터(120)는 하나 이상의 배터리로 구현된 전원(140)을 구비한다. 전원(140)은 AC 어댑터 또는 전력 도킹 크레이들과 같은 내장 배터리에 우선하거나 이를 재충전하는 외부 전원을 더 포함할 수 있다.

도 1에 도시된 예시적인 휴대용 개인용 컴퓨터(120)는 하나 이상의 광 방출 다이오드(LED)(142) 및 오디오 생성기(144)인 3가지 유형의 외부 통신 메커니즘을 구비하는 것으로 도시되었다. 휴대용 컴퓨터 처리기(122) 및 다른 구성요소가 배터리 전력을 절약하기 위해 꺼지더라도, 이러한 장치들은 활성화될 때 통지 메커니즘에 의해 지시된 동안은 유지하도록 전원에 직접 연결될 수 있다. LED(142)는 양호하게는 사용자가 행동을 취하기까지 무한정 유지한다. 오디오 생성기(144)의 최신 버전은 오늘날 휴대용 개인용 컴퓨터 배터리에 대해 너무 많은 전력을 사용하므로, 시스템의 나머지가 꺼질 때에는 꺼지거나 활성화 이후 소정의 시간이 되면 꺼지도록 구성된다는 것을 알자.

기본적인 휴대용 개인용 컴퓨터가 도시되었지만. 데이터 통신을 수신하고 이동 전화와 같은 프로그램에 의해 사용되기 위한 방법으로 데이터를 처리할 수 있는 임의의 장치는 본 발명을 구현하는 목적에 대해 가상적으로 등가이다.

설치를 위해 유효한 소프트웨어 갱신 판정하기

본 발명은 일반적으로 초기 소프트웨어 또는 소프트웨어 갱신이 내장된 장치의, 예를 들면, 플래시 메모리인 비휘발성 메모리에 기입되는 것을 포함하여, 마이크로소프트 윈도우즈 CE .NET 기반 휴대용 장치와 같은 작은 이동 컴퓨팅 장치에 저장된 소프트웨어를 갱신하는 것에 관한 것이다. 그렇더라도, 본 발명은 일반적인 컴퓨팅 이익을 제공하여, 하드디스크 드라이버와 같은 다양한 유형의 메모리 및/또는 다른 유형의 저장 매체를 포함하는 다른 컴퓨팅 장치 및 다른 유형의 저장 장치에 적용할 수 있다. 간단히 하기 위해, 임의의 저장 장치 메커니즘이 등가라는 것을 이해하여야 하지만, 이후 "플래시"라는 용어는 장치의 갱신가능한 저장 장치를 지칭하는 것으로 사용될 것이다. 또한, "영상"이라는 용어는 일반적으로 초기 소프트웨어 설치 영상의 개념은 물론, 기존 영상의 일부에만 갱신이 이루어질 때도 영상에 대한 차후의 소프트웨어 갱신의 개념도 포함할 것이다.

본 발명의 일형태에 따르면, 자체 포함 보안 객체 형태의 사용가능 소트프웨어 갱신의 적절한 부분집합이 효율적이고 지능적(또한 고장 안심적) 방식으로 내장된 장치의 비휘발성 저장 장치에 적용된다. 완전한 대체 갱신 및 이전 갱신에 대한 변경만을 포함할 수 있는 갱신을 포함하는 다양한 유형의 소프트웨어 갱신이 적용될 수 있다. 이러한 소프트웨어 갱신은 설치시 내장된 장치의 가상 주소 공간 환경으로 맞춰진 실행가능 코드인 실행가능 코드 및 데이터 모두를 포함할 수 있다.

단조증가성 갱신과 달리, 초기 제조 영상이 장치에 설치되면, 영상에 대한 갱신은 본 발명을 통해 영상의 이산적인 부분들을 갱신하여 수행될 수 있다. 일구현예에서, 이러한 이산적 부분들은 패키지로 캡슐화되고, 패키지는 영상 파일(코드, 데이터, 스크립 등)의 자체 설명 모음이고, 분배를 위해 서명되고 패키지화된 컴포넌트의 모음을 포함할 수 있다. 본 구현예에서, 전체 운영 체계 영상은 하나 이상의 패키지로부터 생성되고, 그 각각은 각 패키지의 요구사항에 따라 개별적으로 또는 다른 패키지와 결합하여 갱신될 수 있다.

패키지는 소프트웨어 갱신에 관한 다양한 목적을 각각 수행하는 "캐노니컬", "델타/차이", "수퍼" 형태를 포함하는 다양한 방식으로 구성될 수 있다. 예를 들면, 캐노니컬 패키지는 각 파일의 완전한 복사본을 포함하는 반면, 델타/차이 패키지는 파일의 이전 버전에 대한 이진 차이만을 포함하는 하나 이상의 파일을 포함한다. 델타/차이 패키지는 이미 설치된 이전 버전에 적용되고, 다른 패키지와 비교하여 통상 크기가 작고, 다운로드 비용 및 다운로드 시간을 줄이려고 할 때 사용된다. 수퍼 패키지는 여러 패키지를 포함하고, 서로 의존적인 패키지를 갱신하는 때와 같이 하나 이상의 패키지를 다운로드해야 할 때 편리하게 사용된다.

캐노니컬 패키지는 운영 체계 특징과 메타데이터(예, 특정 응용 프로그램의 실행가능 코드 및 관련 데이터 및 구성 정보)를 패키지 정의와 연관시켜 생성 처리 동안 생성된다. 델타/차이 패키지는 이진 차이 알고리듬을 두 개의 캐노니컬 패키지의 콘텐츠에 적용하고, 상기한 것처럼 본 발명을 따라, 델타/차이 패키지가 기본 캐노니컬 패키지 버전에 대해 갖는 의존도 관계를 얻어, 캐노니컬 패키지로부터 생성된다.

본 발명의 일형태에 따르면, 장치에 다운로드된 갱신 패키지의 세트를 조직화하고 검증하는 갱신 검증기/검증 처리가 제공된다. 이 처리의 제1 단계는 패키지를 갱신되는 목표 패키지에 기초하여 일관성있는 그룹(coherent group)으로 조직화한다. 패키지를 그룹으로 조직화한 후, 각 그룹은 갱신을 생성하기 위해 장치상 기존 영상에 적용될 수 있는 패키지의 최소 최적 세트를 판정하기 위해 처리된다. 일관성있는 그룹 각각은 장치상 동일한 기존 패키지를 목표로 하는 패키지 세트를 포함한다. 새로운 패키지의 각각은 다른 기본 버전을 가질 수 있고, 다른 목표 버전에 적용가능할 수 있다.

패키지의 최소 최적 세트를 판정하기 위해서, 패키지는 기본 노드(목표 패키지를 나타냄)에서 잎 노드 각각으로 다중 경로를 가질 수 있는 그래프로 조직화된다. 이는 그래프를 구성하는 패키지의 세트에 걸쳐 최적 경로를 판정하는 것을 용이하게 한다. 각 그룹은 설치하기 위한 그룹내 패키지의 최적 세트를 판정하도록 처리되어, 기존 장치 패키지는 갱신 세트 내 규정된 각 패키지의 가능한 최고 버전으로 갱신된다.

다양한 요인이 이 처리의 결과에 영향을 준다. 예를 들면, 의존도 또는 서명이 검증될 수 없으면, 갱신의 브랜치는 그래프로부터 제거되고, 사용가능한 브랜치가 있으면, 다른 브랜치가 시도된다. 한 브랜치가 갱신되기 위해 얼마나 많은 데이터가 필요한지에 대해 다른 것보다 효율적일 수 있다. 캐노니컬 패키지를 사용하지 않고 갱신을 얻는 모든 방법(즉, 아마도 다중 패키지에서, 최소한 일부 델타를 통해)이 각 파일을 캐노니컬 패키지로 기입(예를 들면, 플래싱)하는 것보다 효율적일 것이기 때문에, 캐노니컬 패키지는 무한 가중치를 갖는 것으로 고려된다. 대안적으로, 캐노니컬 패키지에 대한 실제 가중치를 갖는 것이 가능하다.

그리하여, 그래프는 NK(커널) 파티션 또는 시스템 파티션이든 각 패키지에 대해 생성된다. 파티션은 전술한 관련 미국 특허 출원 "저장 장치 기술 요약 방식 으로 파일 내에 파일 시스템 생성하기(Creating File Systems Within a File in a Storage Technology-Abstracted Manner)"에 일반적으로 설명된 것처럼, 패키지 콘텐츠가 저장될 수 있는 다른 성질을 갖는 완전히 다른 파일 시스템이다. NK 파티션으로 가는 콘텐츠를 갖는 패키지는 그 콘텐츠가 IMGFS 파티션으로 가는 패키지와 동일한 종류의 패키지이다. 그러나, 운영 체계의 로딩/부팅 시퀀스는 NK 파티션이 먼저 로딩되고 NK 파티션의 드라이버가 IMGFS 파티션 파일의 위치를 찾고 로딩하기 위해 사용되는 점에서 NK 및 시스템 갱신이 IMGFS 파티션과 다르다.

각 갱신 패키지에 대한 노드는 그 패키지를 위한 해당 그래프에 추가된다. 그리고, 패키지 메니페스트에 쓰여진 버전 의존도 관계는 그래프의 노드를 연결하기 위해[예를 들면, 패키지의 버전 2는 패키지의 버전 1을 업그레이드할 수 있고, 버전 3는 버전 2(버전 1은 아니고)를 업그레이드할 수 있다] 사용된다. 그리하여, 버전 1과 2 사이 및 버전 2와 3 사이에 에지 연결이 있지만 버전 1과 3 사이에는 없을 수 있다. 상기 버전 관계는 단지 일례를 위한 것이고 관계는 실제 갱신이 생성되는 방법을 따른다는 것을 알아야 한다. 예를 들면, 버전 1 패키지로부터 갱신하는 버전 3 패키지를 생성하는 것이 가능하다. 일반적으로, 각 갱신 패키지는 특정 출발 버전 및 특정 도착(최종) 버전을 구비하고, 그 출발 버전으로부터만 갱신을 할 수 있다(이는 반드시 도작 버전보다 하나 낮은 것이 아니다). 캐노니컬 갱신 패키지는 모든 이전 버전을 갱신할 수 있다는 것을 알자.

그래프가 생성된 후, 예를 들면, 이하 설명된 것처럼 서명을 점검하기 위해서, 이는 다양한 검증 처리를 위해 사용된다. 일반적으로, 그래프 사용 처리는 하 나 이상의 경로가 동일한 버전에 도달하기 위해 사용될 수 있을 때 최소의 부담(가중치)으로 장치가 갱신될 수 있는 최고 버전 찾기를 시도하면서 각 그래프의 경로를 횡단한다. 사용동안, 노드가 검증되지 않으면, 그 노드 및 그 경로는 그래프에서 반드시 제거된다.

패키지 메니페스트에 관해서, 전술한 관련 미국 특허 출원 "자체 설명 소프트웨어 영상 갱신 컴포넌트(Self-Describing Software Image Update Components)"에 일반적으로 설명된 것처럼, 각 패키지 유형은 보다 일반적인 패키지 특성(의존도 정보를 포함함)은 물론 패키지의 콘텐츠 모두를 완전히 설명하는 장치측 메니페스트 파일(예를 들면, .dsm 확장자 포함)을 포함한다. 도 2는 메니페스트 파일의 레이아웃을 나타낸다.

이하 표에서 볼 수 있는 것처럼, 장치 메니페스트 헤더는 특정 패키지의 계통을 고유하게 지칭하는 글로벌하게 고유한 식별자(GUID) 및 특정 패키지 파일을 지칭하는 버전을 포함한다.

typedef struct _DeviceManifestHeader
{
const DWORD dwStructSize; // Size of this structure (in bytes)
// for versioning
const DWORD dwPackageVersion; // Version of this package
const DWORD dwPrevPkgVersion; // Version of package that this package
// updates. (0) for Canonical
const DWORD dwPackageFlags; // package specific identifiers.
const DWORD dwProcessorID; // what processor (matches defines in
// winnt.h)
const DWORD dwOSVersion; // what version of the operating system
// was this built to.
const DWORD dwPlatformID; // what was the target platform.
const DWORD dwNameLength; // length of filename in bytes.
const DWORD dwNameOffset; // offset to Friendly name of package
const DWORD dwDependentCount; // How many entries in Dependent GUID
// list.
const DWORD dwDependentOffset; // How many bytes from the front of the
// file are the dependent GUID structs.
const DWORD dwShadowCount; // How many entries in shadow GUID list.
const DWORD dwShadowOffset; // How many bytes from front of file is
// the array of shadowed package GUIDs.
const DWORD dwFileCount; // How many files are there listed in
// this manifest.
const DWORD dwFileListOffset; // How many bytes from the front of file
// to the first FileEntry.
const DWORD cbCERTData; // number of bytes of digital certificate
// data
const DWORD dwCERTDataOffset; // How many bytes from the front of file
// to the certificate data.
const GUID guidPackage; // GUID of this package
}DeviceManifestHeader, *PDeviceManifestHeader;

typedef struct _DependentEntry {
const DWORD size;
const DWORD version;
const GUID guid;
}DependentEntry,*PDependentEntry;

typedef struct _FileEntry {
const DWORD dwNameLength;
const DWORD dwFlags;
const DWORD dwOffset;
const DWORD dwBase; // Base address that file was originally linked with.
const DWORD dwFileSize; // Size of the whole file. Not accurate for
// update packages.
}FILEENTRY,*PFILEENTRY;

또한, 장치 메니페스트 헤더에는 현재 패키지가 의존하는 패키지의 목록이 보이고, 각각은 다음 구조에 의해 설명된다.

typedef struct _DependentEntry {
const DWORD size;
const DWORD version;
const GUID guid;
}DependentEntry,*PDependentEntry;

각각이 고유하게 GUID에 의해 설명된 임의의 수의 패키지가 있을 수 있다. 한 패키지의 모든 버전은 동일한 GUID를 공유한다. 패키지에 대한 의존도 규칙은 그 패키지가 의존하는 패키지 또는 패키지들이 의존도 목록에서 식별된 버전 번호 이상일 것을 요구한다. 패키지는 이러한 버전이 이미 장치에 설치되었거나 설치가 보류 중이고 그 의존도가 만족되었다면 규정된 버전 이상이다(그리하여 그 설치를 보장함).

일구현예에서 적절한 포맷의 이진 파일인 장치측 메니페스트 파일의 정보에 대한 액세스를 제공하기 위해서, 공통 패키지 정보 API(PackageInfoAPI)가 제공된다. 본 발명은 가능한 설치를 위해 큐잉된 패키지에 대해서는 물론 장치상 패키지에 대한 기존 설치 상태를 판정하기 위해서 패키지 정보 API를 사용한다. API는 내장된 장치 API는 물론 생성 시스템 API로서 존재하고, 일군의 패키지 파일의 장치 메니페스트 파일을 효과적으로 파싱하기 위해 동작한다. 일반적으로, 패키지 정보 API는 장치의 기존 패키지를 나열하고, 특정 패키지에 대한 섀도우 순서 정보(이하 설명됨)를 나열하며, 특정 패키지에 대한 의존도 정보를 나열하고, 특정 패키지에 속한 파일의 파일 이름의 목록을 나열하는 능력을 제공한다. 또한, 패키지 정보 API는 장치측 메니페스트로서 파일 시스템에 저장된 파일을 여는 능력, 규정된 패키지내로부터 장치측 메니페스트를 여는 능력, 특정 패키지에 대한 패키지 정보(예, _PACKAGEINFO)를 검색하는 능력을 제공한다. 또한, 패키지 정보 API는 규정된 파일에 대한 CRC32 값을 그 파일로의 경로가 주어질 때 계산하고, 특정 패키지에 대한 CRC32 값을 그 패키지에 대한 경로가 주어질 때 계산하기 위한 인터페이스를 제공한다. PackageInfoAPI 컴포넌트는 이하 기술된 API의 구현예를 포함한다.

다음의 API 세트는 PackageInfoAPI로의 외부 인터페이스를 정의한다. 데이터 유형은 이하와 같이 설명된다.

ㆍHPKGENUM - 이는 특정 패키지 나열 세트를 식별하기 위해 사용되는 오파크 데이터(opaque data) 유형

ㆍHPKG - 이는 고유 패키지를 나타내기 위해 사용되는 오파크 데이터 유형

ㆍHRESULT - 이는 표준 COM 리턴 유형

ㆍREFGUID - 이는 GUID 구조로의 레퍼런스

ㆍLPTSTR - TCHAR 스트링으로의 포인터

ㆍHFILEENTRY - 호출 프로그램으로 FILEENTRY 정보를 전달하기 위해 사용되는 오파크 데이터 유형

이하 API는 제1 유효한(유효한==악성 '모사자'가 아님) 패키지를 찾고 패키지 정보를 검색하는데 필요한 핸들을 제공한다.

HRESULT Pkg_FindFirstPackage(

/* [out] */ HPKGENUM *phPkgEnum,

/* [out] */ HPKG *phPkg);

이하 API는 다음 유효한 패키지를 찾고 패키지 정보를 검색하는데 필요한 핸들을 제공한다(S_FALSE는 나열의 끝을 표시함).

HRESULT Pkg_FindNextPackage(

/* [in] */ HPKGENUM hPkgEnum,

/* [out] */ HPKG *phPkg);

이하 API는 패키지 나열기를 닫는다.

HRESULT Pkg_FindClose(/* [in] */ HPKGENUM hPkgEnum);

이하 API는 패키지 정보를 검색하는데 필요한 핸들을 제공하는 규정된 GUID를 가지고 장치측 메니페스트 파일을 "열" 것이다. 이는 FindFirstPackage/FindNextPackage를 사용하는 것에 대한 대안이다.

HRESULT Pkg_OpenPackageByGUID(

REFGUID guidPkg,,

/* [out] */ HPKG *phPkg);

이하 API는 패키지 정보를 검색하는데 필요한 핸들을 제공하는 규정된 이름을 가지고 장치측 메니페스트 파일을 "열" 것이다. 이는 FindFirstPackage/FindNextPackage를 사용하는 것에 대한 대안이다.

HRESULT Pkg_OpenPackageByName(

LPCTSTR szFileName,,

/* [out] */ HPKG *phPkg);

// 'close'the package (previously opened with

// Pkg_FindFirstPackage,

// Pkg_FindNextPackage or Pkg_OpenPackageByGUID)

HRESULT Pkg_Close(HPKG hPkg);

// Enumerate shadowed packages. S_FALSE indicates

// the end of the enumeration

HRESULT Pkg_GetNextShadowedPackage(HPKG hPkg, /* [out] */ GUID *pguidShadowedPkg);

// Start enumeration of the GUID dependencies of the // specified package.

HRESULT Pkg_GetFirstDependentPackage(

HPKG hPkg,

/* [out] */ GUID pguidDependentPkg,

/* [out] */ DWORD* pdwDependentPackageVersion );

// Continue the enumeration of GUID dependencies for

// the given package. S_FALSE indicates the end of

// the enumeration

HRESULT Pkg_GetNextDependentPackage(HPKG hPkg, /* [out] */ GUID *pguidDependentPkg, /* [out] */ DWORD *pdwDependentPackageVersion);

// Start enumeration of the files listed in the

// Package. If the buffer is not large

// enough (or is NULL), then cbSize will be set to

// the required size of the

// buffer, including the NUL character at the end.

HRESULT Pkg_GetFirstFile(

HPKG hPkg,

/* [out] */ LPTSTR pszFileName,

/* [in/out] */ DWORD *cbSize );

// Enumerate files in the package. S_FALSE indicates

// the end of the enumeration.

HRESULT Pkg_GetNextFile(HPKG hPkg, /* [out] */ LPTSTR pszFilename, DWORD cbSize );

// Get the single-occurrence info for the package

HRESULT Pkg_GetPkgInfo(HPKG hPkg, /* [out] */ PPACKAGEINFO pPackageInfo);

// Maps the specified file as a DSM file. Returns

// E_FAIL if it is not a DSM.

HRESULT PkgInfo_OpenByName( LPCTSTR szFullName );

// Determine if a specific file is contained within

// the specified package.

// If the named file is part of the package, HFILEENTRY will be non-NULL.

HRESULT Pkg_ContainsFile(

HPKG hPkg,

LPTSTR szFileName,

/* [out] */ HFILEENTRY** pFileEntry );

// Validate the header for the specified Package.

HRESULT Pkg_ValidateHeader(

HPKG hPkg,

DWORD dwFileSize );

// Copies the CERT data from the specified Package

// into the passed in buffer.

// If the buffer is not large enough, or is NULL,

// then pcbBufferSize is set

// to the required size.

HRESULT Pkg_GetCERTData(

HPKG hPkg,

LPVOID lpBuffer,

DWORD* pcbBufferSize );

//and the CRC calculation API (this will be used by

// test, for example, to verify against the CRC

// stored on the device)

HRESULT Pkg_CalculateFileCRC(

LPCTSTR pszFilename,

/* [out] */ DWORD *pdwCRC);

HRESULT Pkg_CalculatePackageCRC(

LPCTSTR pszPackageName,

/* [out] */ DWORD *pdwCRC);

// Opens the CAB, extracts the DSM and maps it.

// Returns E_FAIL if the file doesn't exit or isn't a DSM.

HRESULT PkgInfo_ExtractFrom( LPCTSTR szCABFile );

// Given an HCAB returned by the CABAPI, finds the // DSM, extracts it and maps it. Returns E_FAIL if // the file doesn't exist or is not a DSM.

HRESULT PkgInfo_ExtractFromHCAB( HCAB hCab );

본 발명의 일형태에 따르면, 설치될 모든 패키지는 먼저 검증된다. 패키지 검증은 설치를 위해 큐잉된 패키지가 완벽성에 대해 검토되고, 그 콘텐츠가 검증되고, 갱신 권한이 (서명 메커니즘으로부터) 판정되고, 의존도 관계가 판정되는 처리를 지칭한다. 일구현예에서, 검증 처리의 결과는 검증 요구사항을 통과하여 설치될 수 있는 하나 이상의 패키지의 목록과, 검증 요구사항 중 하나 이상을 만족시키는데 실패하여 설치될 수 없는 하나 이상의 패키지를 각각에 대한 실패 원인과 함께 나열한 목록인 두 가지 목록을 포함한다. 목록은 설치 순서로 소팅될수 있다. 이는 델타가 적용될 때 모든 필요한 파일이 존재할 것을 보장함 외에, 깨어짐을 감소시키기 위해 크기 고려사항에 의존할 수 있고 갱신을 수행하기 위해 충분한 공간이 있음을 보장할 수 있다. 도 3a 및 3b는 전반적인 검증 처리를 설명하는 흐름도를 포함한다.

일구현예에서, 검증 처리는, 예를 들면, 갱신 응용 프로그램에 의해, 호출된 응용 프로그램 인터페이스로서 액세스가능하다. 검증하고 그에 대한 설치 데이터를 리턴하기 위해 갱신의 파일 이름으로 호출되는 기능과, 호출 프로그램이 갱신 패키지가 저장된 디렉토리로의 경로를 제공하는 기능인 두 기능이 있다. 간단히 하기 위해, 갱신은 일반적으로 디렉토리에 있는 것으로 본 명세서에서는 고려할 것이다.

도 3a 및 3b에서, 예를 들면, 하나 이상의 설치될 패키지를 포함하는 디렉토리가 주어질 때, 패키지가 설치될 수 있는지 판정하기 위해서 다수의 시험이 수행 된다. 단계(300)는 패키지의 디렉토리를 취하고, 디렉토리가 존재하는지(단계 302) 및 디렉토리가 파일을 포함하는지(단계 303) 판정하기 위해 시험한다. 그렇지 않다면, 에러 메시지가 단계(306)를 통해 리턴되고, 검증 처리는 종료한다.

디렉토리가 최소한 하나의 파일을 구비하고 존재하면, 단계(308, 322)는 각각에 대해 시험을 수행하면서, 파일의 각각에 걸쳐 반복하도록 루프를 돈다. 단계(310)는 파일이 적절한 유형의 패키지 파일인지를 시험한다. 그렇다면, 단계(312)는 장치측 메니페스트 파일(DSM)을 패키지로부터 추출하려고 시도한다. 보다 구체적으로, 일구현예에서, CABAPI는 CAB 파일로서 파일을 열기 위해 시도하려고 사용된다. 이것이 성공하면, DSM을 추출하기 위한 시도가 이루어진다. 파일이 CAB 파일로서 로딩될 수 없다면, 이름은 규정된 파일 이름이 CAB 파일로서 로딩될 수 없었다는 것을 표시하는 HRESULT 에러 코드를 가지고 나쁜 패키지의 목록에 기록된다. DSM이 추출될 수 없으면, 파일의 이름은 CAB에 DSM이 없었다는 것을 표시하는 HRESULT 에러 코드를 가지고 나쁜 패키지의 목록에 기록된다. CAB이 파일이 없거나, 단계(313)에서 평가한 것처럼 장치측 메니페스트 파일이 찾아지지 않으면, 다음 패키지 파일이 선택되고, 아무 것도 남지 않을 때까지 시험된다.

장치측 메니페스트 파일이 찾아졌을 때, 단계(316)를 통해 패키지는 (예를 들면, 그 패키지에 대한 표현 노드로서) 패키지 그래프에 추가된다. 단계(318)에 의해 시험되면서 성공적이지 않으면, 검증 처리는 노드 생성을 실패한 결과로서 종료한다(단계 320).

각 파일이 처리되었을 때, 그래프는 디렉토리의 최소한 하나의 파일이 장치측 메니페스트 파일을 갖는 패키지 파일이었다면 비어 있지 않아야 한다. 그래프가 비어있다면(단계 323), 어느 파일도 유효한 파일이 아니었고, 처리는 단계(326)에서 종료한다. 아니면, 처리는 도 3b의 단계(328)로 진행한다.

도 3b의 단계(328)(단계 348과 함께)는 그래프의 각 브랜치를 처리하는 루프를 나타내고, 단계(330)(단계 344와 함께)는 현재 처리되고 있는 브랜치의 각 노드를 처리하는 중첩된 루프를 나타낸다. 일반적으로, 처리는 단계(332 및 334)를 통해 부모 노드의 증명 사슬을 점검하고, 단계(336)를 통해 찾아지지 않은 부모 노드로부터 트리로부터의 해당 브랜치를 절단하는 것을 포함하여 증명 정보를 찾는다.

찾았으면, 단계(338 및 340)를 통해 서명이 검증된다. 찾았으면, 가중치 데이터(이는 동일한 결과를 제공하기 위해 하나 이상의 경로가 사용될 수 있을 때 다른 것과 비교하여 어느 패키지가 사용될지를 판정할 때 효율성을 계산하는데 사용됨)가 단계(342)에서 노드에 기초하여 브랜치에 추가되고, 아무 것도 남지 않을 때까지 다른 노드가 단계(344)를 통해 선택된다. 가중치 정보는 패키지가 로딩될 때 계산되고 경로가 형성될 때 경로의 가중치에 추가된다. 초기 그래프 형성은 패키지가 유효하다는 가정에서 동작하므로, 서명 정보는 갱신 세트의 모든 패키지에 이를 수행하기보다는 처리가 사용하기 원하는 패키지에 대해서만 검증될 필요가 있고, 이는 수행되는 서명 점검의 수를 아마도 줄일 것이다. 서명이 단계(340)에서 유효하지 않으면, 단계(346)에서 브랜치는 현재 노드로부터 절단된다.

그래프의 브랜치 및 노드가 이 방식으로 처리되었을 때, 그래프는 최저 가중치 브랜치를 찾기 위해 단계(350)에 나타낸 것처럼 사용되고, 그 브랜치는 리턴될 갱신 목록에 추가된다.

본 발명의 일형태에 따르면, 검증 처리는 설치를 위해 유효한 최대 의존 소프트웨어 갱신의 판정을 가능하게 하는 버전 의존도 계산 요구사항을 제공한다. 도 4의 블럭도로 나타낸 것처럼, 검증 처리(402)는 갱신 순서화 컴포넌트(404)를 포함하여, 판정을 하기 위해 다양한 컴포넌트와 연관된다(또는 포함하는 것으로 고려될 수 있음). 갱신 순서화 컴포넌트(404)는 패키지 메니페스트(410)으로부터 의존도 정보를 추출하고, 다른 패키지(412)가 올바른 버전을 가지고 장치에 존재하는[또는 큐잉된 설치 패키지(414)에 있는] 것을 검증하면서, 갱신 세트(408)로서 장치에 다운로드된 패키지의 세트의 그래프(406)를 생성한다. 또한, 갱신 순서화 컴포넌트(404)는 기존 및 새로운 장치 메니페스트 파일(410, 412)을 파싱하고 의존도 요구사항에 기초하여 패키지에 대한 설치 순서를 생성하는 것을 담당한다.

도 5a 및 5b는 검증 처리의 갱신 순서화 처리를 설명하는 흐름도를 포함한다. 일반적으로, 소정 설치 및 검증 점검 이후(단계 500, 502, 504), 이미 설치된 패키지에 해당하는 장치상 각각의 기존 장치 메니페스트 파일에 대해, 장치에 유지되는 패키지의 장치 메니페스트 파일에 의해 정의된 대로, 그 패키지를 나타내기 위해 갱신 순서화 처리에 의해 패키지 그래프가 생성된다. 검증 처리는 기존 장치 메니페스트를 나열하기 위해 패키지 정보 API를 사용할 수 있다는 것을 알자. 갱신 디렉토리의 패키지는 단계(506)에서 그 패키지에 대한 적절한 기본 그래프에 추가된다. 기존 그래프가 찾아지지 않으면, 새로운 패키지를 위해 하나가 생성되지만 비기본 그래프로서 태그된다. 노드는 메니페스트 및 패키지에 기초한 정보를 포함하고, 추가될 때, 어느 노드 또는 노드들이 패키지가 갱신할 수 있는 어떤 버전 또는 버전들에 기초하여 연결될지를 판정하기 위해서 버전 정보를 위해 그래프의 다른 노드를 본다. 그래프에 추가되고 있는 패키지를 갱신할 수 있는 그래프의 단독 노드들이 있을 수 있다는 것을 알자. 그래프 형성 처리는 그래프를 형성하는 노드를 이용하고, 새로운 노드를 갱신할 수 있는 그래프의 기존 노드가 있을 때 적절한 링크를 추가한다.

설치될 패키지가 추가되었다면, 각 그래프는 경로를 계산하고 파일 검증을 수행하기 위한 목적을 위해 사용된다. 그래프를 통한 경로는 노드가 그래프에 추가되면서 실시간으로 형성된다는 것을 알자. 도 6을 참조하여 설명된 것처럼, 패키지가 로딩되었으면, 갱신 검증은 그래프를 위해 사용가능한 경로의 세트 중에서 최적 경로를 찾기 위해 각 그래프를 사용한다. 경로가 그래프를 위해 선택된 후, 경로의 노드를 위한 서명이 검증된다. 특정 노드를 위한 서명이 검증될 수 없다면, 경로는 실패 노드에서 시작하여 절단되고, 경로 선택 처리는 그 그래프에 대해 다시 실행된다. 이 처리는 경로의 노드가 유효한 서명을 가진 것으로 판정되거나 주어진 그래프를 위해 처리할 경로가 없을 때까지 반복된다.

처리가 단계(514)에서 성공적이면, 갱신 순서화 처리는 도 5b의 단계(518)로 진행하고, 결과적인 각 패키지 그래프에 대해, 패키지가 NK 파티션의 일부이면, 패키지 정보는 단계(522)를 통해 NK 목록(416)(도 4)에 추가된다. 패키지가 NK 파티션의 일부가 아니면, 패키지 정보는 다른 목록(418)(도 4)에 추가된다. 모든 패키지 그래프가 처리되면, 단계(532)를 통해 다른 목록(418)이 NK 목록(416)에 첨부된다. 단계(534)에서 평가한 것처럼 첨부가 성공하면, 첨부된 NK 목록(416) 및 비유 효 목록(420)과 함께 비에러 상태를 리턴한다.

검증 처리(402)의 다른 부분은 갱신 그래프를 형성하는 것에 관한 것이고, 장치상 갱신을 포함하는 패키지의 그래프의 생성을 담당하는 갱신 그래프 컴포넌트(422)에 의해 달성된다. 장치상 각 기존 패키지는 독립 그래프를 위한 기본 노드를 생성하도록 사용될 것이다. 일구현예에서, 각 패키지는 패키지 노드 객체에 의해 표현된다. 본 구현예에서 각 노드 객체는 하나, 및 단지 하나의 패키지 그래프 객체 안에 포함된다는 것을 알자.

그래프 형성 처리는 도 6에 도시되어 있다. 일반적으로, 갱신 그래프(424)(도 4)는 노드 객체(436)의 어레이 및 에지 객체(428)의 어레이를 포함하는 두 어레이를 포함한다. 에지 객체는 노드를 서로 연결한다. 새로운 패키지가 그래프에 추가될 때, 노드 객체는 단계(600)로 나타낸 것처럼 패키지를 위해 생성되고 노드 어레이(426)에 추가된다. 노드가 단계(602)에서 평가된 것처럼 생성되지 않으면, 처리는 실패한다.

단계(606, 608)는 이 패키지에 해당하는 기존 그래프를 찾기 위해 시도한다. 아무 것도 찾지 못하면, 단계(610)에서 패키지는 새로운 것이고 그래프는 이를 위해 생성된다[그리고, 단계(612)를 통해 적절하게 생성되는 것을 보장함]. 성공적으로 생성되면, 새로운 그래프는 단계(616)에서 리턴되고, 아니면, 실패가 리턴된다.

노드 생성이 성공적이고 그래프가 그 패키지를 위해 찾아졌으면, 단계(608)는 단계(618)로 진행하여, 노드 어레이의 각 노드에 대해, 단계(618-630)를 통해, 새로운 노드의 기본 버전이 기존 노드를 위한 버전 번호와 일치하면, 에지 객체는 갱신 그래프(424)에서 생성되고(도 4) 어레이(428)에 추가된다. 이 조건에서, 에지 객체는 소스로서 기존 노드를 규정하고 싱크로서 새 노드를 규정한다. 반면, 기존 노드의 기본 버전이 새 노드의 버전 번호와 일치하면, 에지 객체는 새로운 노드를 소스로 규정하고 기존 노드를 싱크로 규정하여 생성된다.

추가시에, 임의의 기존 노드에 연결됨 없는 패키지가 추가되는 것이 가능하다는 것을 알자. 이 조건은 두 결과 중 하나를 통해 정규화될 것이다. 즉, (a) 이 패키지 노드를 통해 도달될 수 있는 노드가 없고 갱신에서 다른 패키지 노드를 통해 이 패키지 노드에 도달될 수 있는 경로가 없다. 이 환경에서, 노드는 나쁜 것으로 표시되고 비유효한 갱신 목록에서 종료할 것이다. 또한, (b) 이후 추가될 패키지는 노드에 연결할 것이다. 이 환경에서, 노드는 도 7a 및 7b를 참조하여 이하 설명된 그래프 사용 단계에서 처리될 것이다.

또한, 두 패키지가 동일한 목표 버전을 가진다면, 두 장치측 메니페스트 파일이 비교된다는 것을 알자. 같다면, 모든 주어진 패키지에 대해, 특정 버전을 위한 장치측 메니페스트 파일이 주어진 패키지를 특정 버전으로 갱신하는 모든 패키지에 대해 동일하여야 하므로 두 노드는 비유효한 것으로 표시된다.

검증 처리의 다른 부분으로서, 갱신 그래프 사용 컴포넌트(430)는 그래프를 통해 가능한 다중 경로에 기초하여 패키지를 위한 최고의 최종 버전 번호를 판정하기 위해서 각 패키지 그래프를 횡단한다. 사용하면서, 갱신 그래프 사용 컴포넌트(430)는 그래프의 패키지의 디지털 서명을 검증한다. 서명 점검이 실패하면, 그래 프는 그 지점에서 절단되고, 실패한 노드에 연결된 모든 에지는 제거된다.

최고 버전 번호가 판정된 후, 그 노드에 대한 의존도가 검증된다. 이는 의존 GUID와 일치하는 패키지 그래프에 대해 갱신 그래프(424)에 문의하여 달성된다. 새로운 갱신 그래프는 검증되지 않았다면, 갱신 그래프 사용기는 새로운 패키지 그래프에 대해 사용 처리를 시작한다. 의존도가 만족될 수 없으면, 브랜치는 버려지고 새로운 브랜치가 시도된다. 브랜치의 노드를 연결하는 에지는 제거된다. 모든 가능한 브랜치가 쓰여지고 의존도 요구사항이 만족될 수 없으면, 그래프의 노드가 나타내는 패키지는 비유효 갱신 목록에 이동된다.

도 7a 및 7b는 그래프에 대해 기본 노드에서 시작하는 횡단 처리의 로직을 나타낸다. 단계(702-706)로 나타낸 것처럼, 그래프의 각 에지에 대해, 에지가 소스로서 노드를 갖는다고 판정된다(단계 704). 노드와 연관된 에지가 없으면, 종단 노드가 검출되었고, 단계(708-718)에서 처리된다. 일반적으로, 이러한 단계는 그래프 버전 번호와 노드의 버전 번호를 비교하고(단계 714), 노드 버전이 그래프 버전보다 높으면, 단계(716)에서 그래프 버전은 노드 버전으로 갱신되고, 처리는 종료한다(리턴되는 에러 없음).

이와 달리 단계(704)에서 에지가 있으면, 처리는 노드가 CERT 사슬을 갖는지 를 알아보기 위해 점검하기 위해 도 7b의 단계(724)로 간다. 단계(724)에서 증명 사슬이 없으면, 증명 블럭은 노드에 해당하는 장치측 메니페스트 파일로부터 얻어진다. 증명 블럭이 장치측 메니페스트 파일에 없으면, 노드는 단계(730)에서 나쁜 것으로 표시되고, 처리는 리턴한다.

증명 데이터가 단계(724) 또는 단계(728)에서 있으면, 처리는 데이터를 디코딩하기 위해 단계(734)로 진행한다. 디코딩이 실패하면, 노드는 단계(730)에서 나쁜 것으로 표시되고, 처리는 리턴한다.

이와 다르면, 에지의 끝에서 싱크 노드를 찾기 위한 시도가 단계(738)에서 수행되고, 싱크 노드가 있는지를 단계(740)에서 시험한다. 없으면, 그래프 무결성 에러가 기록되고, 처리는 단계(742)를 통해 리턴한다.

싱크 노드가 찾아지면, 증명 데이터는 싱크 노드를 검증하기 위해 사용된다(단계 744). 싱크 노드가 서명 검증을 통과하면, 이 기능은 싱크 노드를 단계(748)에서 통과시키면서 반복적으로 호출되고, 도 7a의 단계(720)로 리턴한다. 싱크 노드가 실패하면, 에지는 나쁜 것으로 표시된다.

이 방식에서, 갱신의 최대 세트가 판정되고, 모든 비유효한 갱신의 목록과 함께, 순서화된 갱신 목록으로 리턴된다. 이는 장치 패키지 버전을 최대화하는 패키지의 최소 번호에 해당한다.

본 발명은 다양한 수정예 및 대안예 형성이 가능하지만, 그에 대한 도시된 소정 실시예가 도면에 도시되었고 상세하게 상기에 설명되었다. 그러나, 본 발명을 개시된 특정 형태로 한정하는 의도는 없으며, 반대로, 본 발명의 사상 및 범위 내에서 모든 수정예, 대안적 형성, 등가물을 포함하기 위한 의도이다.

전술한 상세한 설명에서 알 수 있는 것처럼, 장치측의 장치 갱신을 처리하는 메커니즘이 제공된다. 메커니즘은 장치 패키지의 버전을 최대화하며 적용될 때 유 효한 패키지의 최소 번호를 제공하기 위해서 많은 갱신 버전 및 이러한 버전 사이의 충돌 및 의존도를 가지고 다룬다.

Claims

복수의 이산 패키지로 분할된 운영 시스템이 설치된 컴퓨팅 환경 - 상기 설치된 운영 시스템의 제1 패키지를 갱신하는 데 복수의 버전의 갱신이 가용함 - 에서, 패키지 의존도 제약을 지키면서, 가능한 가장 적은 갱신 단계로 상기 제1 패키지의 최대 버전의 갱신들(maximal version updates)을 허용하도록 가용한 버전들의 최적 세트를 선택하는 방법으로서,

모바일 컴퓨팅 장치에 설치된 운영 시스템을 갱신하기 위한 갱신 패키지들의 콜렉션을 상기 모바일 컴퓨팅 장치로 다운로드하는 단계 - 상기 운영 시스템은 각각 다른 패키지들과 독립적으로 갱신될 수 있는 복수의 이산 패키지로 분할되어 있으며, 상기 갱신 패키지들의 콜렉션은 상기 모바일 컴퓨팅 장치상에 상기 설치된 운영 시스템의 설치된 제1 패키지의 다른 버전들에 대응하는 복수의 갱신 패키지를 포함하고, 각각의 갱신 패키지는 상기 갱신 패키지의 버전을 포함하는 상기 갱신 패키지의 콘텐츠 및 관련된 의존성 정보를 기술하는 연관된 메니페스트(manifest) 파일을 포함함 -;

상기 모바일 컴퓨팅 장치상의 상기 설치된 운영 시스템의 각각의 패키지에 대하여, 상기 패키지의 설치된 버전을 위한 노드를 갖는 그래프를 생성하는 단계 - 상기 그래프는 상기 패키지의 설치된 버전에 대응하는 메니페스트 파일로부터 생성됨 -;

설치될 상기 갱신 패키지들 각각에 대하여, 상기 갱신 패키지가 어떠한 설치된 패키지에 의존하는지 판정하기 위해 상기 연관된 메니페스트 파일에 엑세스하는 단계 - 각각의 갱신 패키지는 설치된 패키지에 직접 의존함으로써 혹은 설치된 패키지 또는 또 다른 갱신 패키지에 직접 순차적으로 의존하는 또 다른 갱신 패키지에 순환적으로(recursively) 의존함으로써 설치된 패키지에 의존할 수 있으며, 상기 갱신 패키지가 어떠한 설치된 패키지에 의존하는지 판정할 때, 상기 갱신 패키지의 버전에 대응하는 새로운 노드를 상기 그래프에 추가하며, 이로써 상기 갱신 패키지들 각각에 대한 새로운 노드를 추가할 때 각각의 그래프는 상기 그래프의 베이스(base)에 상기 설치된 버전에 대한 상기 노드를 갖고 상기 새로운 노드 각각에 대한 브랜치(branch)들을 갖는 트리로서 형성되고, 상기 새로운 노드 각각은 자신이 의존하는 다른 노드에 링크되고, 동일한 그래프의 각각의 새로운 노드는 상기 그래프가 나타내는 상기 설치된 패키지의 상이한 버전에 대응함 -;

상기 그래프들을 생성하는 것에 후속하여, 상기 설치된 운영 시스템의 상기 제1 패키지에 대응하는 상기 그래프가, 상기 제1 패키지가 갱신될 수 있는 가장 높은 최종 버전에 대응하는 노드를 각각 포함하는 두 개의 경로를 포함하는 것을 판단하는 단계;

상기 두 개의 경로를 식별하는 것에 후속하여, 각각의 경로를 순회(traversing)하면서, 순회한 각각의 노드를 검증(validating)하는 단계;

두 개의 경로의 각각의 노드를 검증할 때, 가장 낮은 설치 비용을 갖는 경로를 선택하는 단계 - 경로 상의 각각의 버전은 설치 비용이 있으며, 각각의 경로의 설치 비용은 상기 경로 상의 각각의 버전의 설치 비용의 총합을 포함함 -; 및

상기 설치된 운영 시스템의 상기 제1 패키지를 갱신하기 위해 상기 선택된 경로의 각각의 노드에 대응하는 상기 갱신 패키지를 설치하는 단계

를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

각각의 갱신 패키지가 목표로 하는 상기 모바일 컴퓨팅 장치상의 현재 설치된 패키지에 기초하여 상기 갱신 패키지들의 콜렉션을 일관성있는 그룹(coherent group)들로 조직화하는 단계를 더 포함하는 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 두 개의 경로에서 노드를 가장 적게 갖는 경로가 선택되는, 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 각각의 노드를 검증하는 단계는, 상기 노드에 대응하는 상기 갱신 패키지와 연관된 파일에 엑세스하여 상기 파일이 적합한 형식의 패키지 파일인지 판단하는 단계를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 각각의 노드를 검증하는 단계는, 상기 노드에 대응하는 상기 갱신 패키지가 상기 갱신 패키지의 컨텐츠를 기술하는 연관된 메니페스트 파일을 포함하는지 여부를 판단하는 단계를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 생성된 그래프 중 어떠한 것도 상기 갱신 패키지에 대응되지 않음을 판단하는 단계와, 이에 응답하여 새로운 그래프를 생성하는 단계 및 상기 갱신 패키지의 상기 버전에 대응하는 노드를 상기 새로운 그래프에 부가하는 단계를 더 포함하는 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 순회한 각각의 노드를 검증하는 단계는, 증명 사슬(certificate chain)이 부모 노드(parent node)를 통해 주어진 노드와 연관되어 있는지 여부를 판단하는 단계를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제7항에 있어서,

증명 사슬이 상기 주어진 노드와 연관되며, 상기 순회한 각각의 노드를 검증하는 단계는, 상기 노드에 대응하는 상기 패키지가 유효 서명을 포함하는지 여부를 확인하는 단계를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제8항에 있어서,

상기 서명은 상기 주어진 노드에 대해 유효하고,

상기 주어진 노드에 기초한 경로에 가중 데이터를 부가하는 단계를 더 포함하는 가용한 버전의 최적 세트를 선택하는 방법.
제9항에 있어서,

최저 가중 경로를 발견하기 위해 상기 패키지의 그래프를 순회하는 단계 및 상기 최저 가중 경로에 대응하는 정보를 갱신 리스트에 부가하는 단계를 더 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
제7항에 있어서,

적어도 하나의 노드는 상기 그래프에 잔존하고, 적어도 하나의 잔존하는 노드는 연관된 가중치를 갖는 경로에 있으며,

최저 가중 경로를 발견하기 위해 상기 그래프를 순회하는 단계 및 상기 최저 가중 경로에 대응하는 정보를 갱신 리스트에 부가하는 단계를 더 포함하는 가용한 버전의 최적 세트를 선택하는 방법.
제1항에 있어서,

상기 운영 시스템의 설치를 위해 각각의 버전을 선택하는 단계는, 상기 각각의 버전에 대응하는 파티션(partition)을 판단하는 단계 및 상기 각각의 버전에 대응하는 파티션에 기초하여 상기 각각의 버전을 각각의 리스트에 부가하는 것에 의해 상기 각각의 버전을 리스트들로 소팅하는 단계를 포함하는, 가용한 버전의 최적 세트를 선택하는 방법.
실행되는 경우 제1항의 방법을 수행하는 컴퓨터 실행가능 명령어들을 저장하는 하나 이상의 컴퓨터 판독가능 저장 매체.
제13항에 있어서,

상기 각각의 노드를 검증하는 단계는, 상기 노드에 대응하는 상기 갱신 패키지와 연관된 파일에 엑세스하여 상기 파일이 적합한 형식의 패키지 파일인지 판단하는 단계를 포함하는, 하나 이상의 컴퓨터 판독가능 저장 매체.
제13항에 있어서,

상기 각각의 노드를 검증하는 단계는, 상기 노드에 대응하는 상기 갱신 패키지가 상기 갱신 패키지 콘텐츠를 기술하는 연관된 메니페스트 파일을 포함하는지 여부를 판단하는 단계를 포함하는, 하나 이상의 컴퓨터 판독가능 저장 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제