KR20010033354A

KR20010033354A - 자동 컨피규레이션 생성

Info

Publication number: KR20010033354A
Application number: KR1020007006819A
Authority: KR
Inventors: 카디르 비. 리; 스코트 더블유 데일
Original assignee: 서포트. 콤, 인코포레이티드
Priority date: 1997-12-18
Filing date: 1998-12-16
Publication date: 2001-04-25
Also published as: KR100623245B1; IL136836A; WO1999031577A2; IL136836A0; JP2002508561A; WO1999031577A3; EP1040411A2; US6442684B1; US6158001A; BR9814309A; CN1113291C; US5996073A; CN1284181A

Abstract

컴퓨터 구현 시스템이, 유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하고, 상기 규정된 엔터티들에 종속하는 아이템들을 규정하고, 겹친 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 그룹핑하고, 소정의 포맷을 사용하는 엔터티들의 그룹을 패키징함으로써, 애플리케이션 상태를 분석한다. 본 시스템은, 정확한 애플리케이션 기능에 필요한 기본 데이터, 메타데이터 및 디펜던시들을 결정론적인 방식으로 계수하기 위해, 커런트 머신 상태에 기초한 자동 관련성 분석을 제공한다. 추가적으로, 상태 정보는, 설치, 동기, 백업, 복구, 분석 및 수리를 포함하는 다양한 애플리케이션에 사용되는 영속적인 포맷에 저장된다.

Description

자동 컨피규레이션 생성{AUTOMATIC CONFIGURATION GENERATION}

역사적으로, 소프트웨어 애플리케이션들은, 전형적으로, 중앙 컴퓨팅 센터에서 메인프레임 상에 배치-처리되었다. 좀더 최근, 값싸지만 강력한 퍼스널 컴퓨터들의 유용성이, 과거의 배치-처리 모드를 대신하게 되었다. 유저 중심의 생산성 향상형 소프트웨어의 광범위한 유용성 때문에, 퍼스널 컴퓨터는 어디에나 있게 되었다. 사용자들의 특정한 요구에 대해 더 원활하게 주문을 받아 만들어짐에도 불구하고, 퍼스널 컴퓨터들이 확산됨으로 인해, 대규모의 컴퓨팅을 관리하는 잡(job)은 더 곤란하게 되고 있다. 과거에는, 컴퓨팅 센터 내의 메인프레임은, 라이브러리 및 컨피규레이션 관리(configuration management) 그리고 소프트웨어 버전 제어 등을 포함하는, 중앙 시스템 관리 태스크들을 수행했다. 그러나, 다양한 프로세서들, 주변기들 및 소프트웨어 애플리케이션들을 갖는 현대의 네트워크에서는, 가능한 컨피규레이션의 범위가 흔들리고 있다.

몇몇 컨피규레이션 정보는, 디스크 제어포트 어드레스, 통신포트 어드레스 및 비디오포트 어드레스들과 같은 하드웨어 사양이다. 더욱이, 소프트웨어 사양 구성 파라미터들은, 각 애플리케이션용 구성 파일 내에 세팅될 수 있다. 예를들어, autoexec.bat 파일로 알려진 IBM 호환 퍼스널 컴퓨터 내에 저장된 구성 파일은 경로 제시를 포함할 수 있다. 추가적으로, 특정 응용 소프트웨어는 효과적인 실행을 위해 특정한 개시 정보를 필요로 할 수 있다. 전형적으로, 이 정보는, 개시(.ini) 파일에 세팅될 수 있다.

그러나, 일단 인스톨되면, 컴퓨터 컨피규레이션은 더 이상 정적인 상태로 남아있지 않게 된다. 유저는, 파일 열기/저장 경로들을 업데이팅하는 것과 같이, 소프트웨어를 동작시키는 동안, 구성가능한 선택물(preferences)을 업데이트할 수 있다. 추가적으로, 유저는, 예를들어, 월드-와이드-웹(WWW) 브라우저의 경우에 북마크 데이터와 같은 새로운 정보를 추가함으로써, 소프트웨어를 자신에게 맞출 수 있다. 더욱이, 더 좋은 제품을 만들어야 한다는 끊임없는 경쟁 압박 때문에, 소프트웨어 발매물이 유저에게 배달될 때까지, 소프트웨어 개발자는 다음 발매물에 대한 작업을 이미 시작하고 있다. 더 접근하기 쉽고 더 기능적인 애플리케이션들에 대한 늘어나는 수요를 극복하기 위해, 소프트웨어 개발자들은, 점점 컴포넌트 모델을 채택하여 왔는 바, 애플리케이션은 다수개의 모듈이나 컴포넌트들로 바뀐다. 하나의 컴포넌트에 대한 변형이 이루어져서, 나머지 컴포넌트들의 상태를 손상시키지 않고서는 이전에는 유용하지 않았던 새로운 특징을 구현하거나 그 성능을 향상시키는 것이 가능하게 되었다. 이러한 패러다임 하에서, 소프트웨어 애플리케이션은 많은 별도의 파일들의 집합체이며, 그들 각각은, 조립 패키지의 완전성(integrity) 보다 각 컴포넌트의 완전성에 대하여 더 잘 알고 있는, 관련없는 소프트웨어 개발자들에 의해 생성될 수 있다. 소프트웨어 재사용이 증진될 지라도, 그러한 패러다임은, 컴포넌트간 완전성의 더 높은 레벨을 요한다. 당연히, 업데이트가 더 빈번하게 되면 유저들에게 더 기능적인 소프트웨어를 가져다주게 될지라도, 발매물의 설치를 관리하는데 따른 복잡성은, 변경 횟수에 따라 불균형적으로 증가한다.

역사적으로, 컴포넌트들 간의 관련성은, 수동적으로 검출되어져 왔으며, 컴포넌트 상태들은 로그(log) 내에 기록되었다. 이 정보는, 컴포넌트들 자체의 외형이며, 컴포넌트들이 변할 때마다 업데이트되어져야 한다. 상태 정보가 개발 시에만 기록되므로, 개발 시점 이후에 만들어지는 변화를 잃어버릴 수 있다. 변화 속도가 증가하며 소프트웨어 조립 과정의 복잡성이 증가하므로, 컴포넌트들 간의 정확한 상태 관련성의 외형적 표시는 틀리기 쉽게 된다.

더욱이, 사용 도중, 유저들은 소프트웨어를 개인에게 맞추며 따라서 상태 정보를 변화시킬 수 있다. 소프트웨어 설치 및 소프트웨어 동작간의 상태 정보의 차이는 예기치 못한 동작을 가져오게 되며, 정보 시스템 (SI) 인사부로부터 더 많은 지원을 요구할 수 있다.

상업적으로 실시되는 소프트웨어 애플리케이션들이 현 상태를 유지하는 것은, 소프트웨어 설치, 동기, 백업, 분석 및 수리를 포함하는 다양한 애플리케이션에 있어서 요구된다. 부적절하게 설치되었을 경우 하나의 문제점을 정정하기 위해 하나의 컴포넌트를 변형하는 것이 다른 에러를 야기할지도 모를 상황을 방지하기 위해, 컴퓨터 동적 환경 및 그 시스템 구성에 대해 상세한 지식이 요구된다. 더욱이, 호환성을 확증하고 다중 오퍼레이팅 환경들간의 완전성 및 다양한 프로세서들간의 완전성을 보증하기 위해, 시스템 구성에 대한 정확한 지식이 요구된다.

발명의 요약

본 발명은, 유저에 대해 소정의 기능성을 제공하는 엔터티(entity)들을 규정하고, 상기 규정된 엔터티들에 종속하는 아이템들을 규정하고, 중복되는 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 그룹핑하고, 소정의 포맷을 사용하는 상기 엔터티들의 그룹을 패키지화함으로써, 애플리케이션 상태를 규정한다. 본 시스템은, 기본 데이터, 메타데이터 및 정확한 애플리케이션 기능에 필요한 디펜던시들(dependencies)을 결정론적 방식으로 계수(enumerate)하기 위한, 커런트 머시인 상태에 기초한 자동 관련성 분석을 제공한다. 애플리케이션에 대한 완벽하고 변함없는 런타임 상태 정보가 생성되는 바, 그것은 컴퓨터 시스템의 설치, 동기, 백업, 복구, 분석 및 수리에 사용될 수 있다.

본 발명의 일 측면에 의하면, 유저 접근성의 티어(tier)들을 규정함으로써 엔터티들이 분석된다. 더욱이, 각 티어에 대해, 루트 엔터티(root entity)들이 소정의 기준에 기하여 계수된다. 각 계수된 엔터티에 대해, 상기 엔터티의 하나 이상의 디펜던시들이 결정된다.

다른 측면에 의하면, 아이템 디펜던시는, 하나 이상의 후보들을 생성하고, 그 후보들을 분석하고, 그 후보들을 확인하고, 그 후보들과 연관된 아이템들을 패키지화 함으로써 결정된다.

또다른 측면에 의하면, 상기 엔터티 그룹핑 및 패키징은, 엔터티간 관련성을 규정하고, 상기 엔터티간 관련성에 기하여 상기 엔터티들을 처리하고, 상기 엔터티들을 소저의 포맷 내에 위치시킴으로써, 달성된다.

또다른 측면에 의하면, 상기 포맷은, 각 아이템 및 각 엔터티에 대한 상세한 정보를 포함한다. 상기 포맷은 0개나 1개의 정보 블록 및 하나 이상의 엔터티 블록을 가진다. 다중 정보 블록들은, 그들과 결합된 엔터티 블록들과 함께, 상호 그룹핑될 수 있다.

본 발명의 장점은 다음을 포함한다. 본 발명은, 컴포넌트들 자체로부터 정확한 상태의 외형적 표시를 동적으로 재구성한다. 더욱이, 상태 구성 과정이 동적이기 때문에, 본 발명은, 그 전체 라이프 사이클을 통해 소프트웨어를 추적할 수 있으며, 실행 도중 상기 애플리케이션에 관한 상세한 정보를 필요로 하는 많은 관리 태스크에 대한 정보를 제공할 수 있다.

본 발명은 자동 컨피규레이션 생성에 관한 것이다.

도 1 은, 응용 소프트웨어의 런타임 상태를 분석하는 프로세스의 플로우챠트이다.

도 2 는, 루트 엔터티들을 규정하는 프로세스의 플로우챠트이다.

도 3 은, 아이템 디펜던시를 규정하는 프로세스의 플로우챠트이다.

도 4 는, 그룹을 결정하고 엔터티들을 패키징하는 프로세스의 플로우챠트이다.

도 5 는, 응용 소프트웨어의 특성을 나타내는 포맷의 블록도이다.

도 6 은, 데스크탑 구성의 예시이다.

도 7 은, 마이크로 소프트 오퍼레이팅 시스템과 같은 오퍼레이팅 시스템을 실행하는 컴퓨터 상에서 논리 엔터티들을 분석하고, 기술하고, 복제하는 프로세스의 플로우챠트이다.

도 8 은, 도 7 의 컴퓨터의 데스크탑 상에서 엔터티들을 분석하는 프로세스의 플로우챠트이다.

도 9 는, 아이템들을 생성하는 프로세스의 플로우챠트이다.

도 10 은, 도 7 의 프로세스와 관련하여 모듈들을 스캐닝하는 프로세스의 플로우챠트이다.

도 11 은, 그 상태가 본 발명에 따라 결정되어야 할, 소프트웨어를 포함하는 컴퓨터의 개략적인 다이어그램이다.

본 명세서에서 사용되듯이, 후보(candidate)란, 하나 이상의 아이템을 생성하는데 사용되는 정보를 포함하는 데이터 패킷이다. 아이템은, 다른 아이템들과 디펜던시들을 갖거나 갖지 않고 동작될 수 있는 데이터의 기본 단위 (즉, 메타데이터) 에 관한 것이다. 엔터티는 아이템의 그룹이다. 엔터티는, 컴퓨터 시스템용 또는 유저용 소정의 기능성의 집합을 나타낸다. 그 가장 간단한 형태에서, 엔터티는, "Corel WordPerfect", "Microsoft Excel"과 같은 단일 애플리케이션을 나타낼 수 있다. 엔터티는 또한, 프린터 세팅, 폰트 세팅, 네트워크 디바이스 세팅 등과 같은 하나 이상의 오퍼레이팅 시스템 세팅에 관한 정보를 포함할 수 있다. 더욱이, 엔터티는 또한, 데이터 파일, 초기화 파일, 소스 파일, 템플리트 파일 등과 같은 파일에 관한 정보를 포함할 수 있다. 각 엔터티는, 컴퓨터 시스템 내에서 이용가능한 전체 기능의 논리 서브셋인 상태를 갖는다. 이 시스템 상태는, ".exe" 파일, ".dll" 파일, ".ocx" 파일과 같은 실행 파일에 관한 정보를 포함할 수 있다. 머시인 상태는 또한, 특정시점에서 데이터 파일, 지원 파일, 환경 변수 및 등록 세팅(registry settings)을 포함할 수 있다.

이제 도면을 참조하면, 도 1 은, 소프트웨어 애플리케이션의 런타임 상태를 규정하는 프로세스를 도시하는 플로우챠트이다. 도 1에서, 상기 프로세스는, 유저용 기능의 소정의 세트에 관한 하나 이상의 엔터티들의 존재를 초기에 결정한다 (스텝 22). 엔터티가 유저용의 모든 유용한 기능을 기술하듯이, 따라서 루트 엔터티는, 또다른 머시인에서, 또다른 장소에서, 혹은 또다른 시간에, 유저에 의해 완전히 자기-충족적 방식(self-sufficient manner)으로 수행될 수 있는 오브젝티브를 나타낸다.

다음, 프로세스는, 아이템 디펜던시들을 결정하는 바, 이들은 시간 스텝 24에 걸쳐 변할 수 있다. 아이템 디펜던시들의 결정은 또한, 모든 디펜던시들을 위치시키고 한정된 세트의 디펜던시들을 생성하는 완벽하고 결정적인 프로세스이다. 상기 프로세스는, 중복된 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 세트로 그룹화한다. 더욱이, 아이템의 임의의 디펜던시들에 대해 어떤 변화도 만들어지지 않는다고 가정하면, 불변의 아이템에 대한 상태 생성은, 모든 이전의 상태 생성들과 일관적이며 균등할 것이다. 마지막으로, 프로세스는, 종료 (스텝 28) 전에, 엔터티들을 이후 유저들에게 적합한 포맷으로 패키지화한다. 스텝 26 의 엔터티들을 그룹핑하는데 있어서, 엔터티들의 패키지가 간결하게 정의될 수 있도록 그리고 그에 필요한 모든 정보가 실제적인 엔터티들을 갖거나 갖지 않는 파일로 나타내어질 수 있도록, 엔터티들의 인터섹션(intersection)이 규정된다. 각 엔터티에 대한 충분한 정보가 포함되며, 그리하여 정확성의 분석이 행하여질 수 있다.

이제 도 2를 참조하면, 스텝 22 (도 1) 가 더 상세히 보여진다. 도 2 에, 유저 접근성(accessibility)의 하나 이상의 티어들이 규정된다(스텝 30). 상기 티어들의 결정은 부분적으로 애플리케이션에 대한 유저 접근성의 용이함에 기초한다. 하나의 티어가, 프로세싱 큐(queue)에서 그 우선 순위에 기하여 선택된다 (스텝 32). 전형적으로, 그 큐에 남아있는 가장 우선 순위가 높은 티어가 선택된다. 선택된 티어에 대해, 소정의 기준에 기하여, 하나 이상의 루트 엔터티들이 계수된다 (스텝 34). 상기 소정의 기준은, 예를들어, 엔터티의 상태 및 유저에 대해 파악된 유용성에 관한 것일 수 있다. 오퍼레이팅 시스템 종속적인 티어 정보는, 그 티어 내에 존재할 수 있는 엔터티들을 보여준다. 추가적으로, 엔터티들의 계수는 그 엔터티들이 이미 처리되었는가 또는 제외되었는가에 기초하므로, 엔터티들이 멀티플 티어나 크로스 티어들 내에 포함되는 한, 트랙 상황에 대해 처리된 엔터티들의 기록이 유지된다.

스텝 34에서 계수된 엔터티들의 각각에 대해, 아이템 디펜던시들이 규정된다 (스텝 36). 이 단계는, 티어 내에서 발견된 데이터를 실제의 아이템으로 번역하는 바, 이는 실행 파일 또는 데이터 파일이다. 이 단계는 또한, 엔터티들을 루트 아이템으로 번역하는 것이다. 일례는, 링크 파일로부터 실행 파일로 또는 데이터 파일로부터 그 데이터 파일을 액세스하는 실행 파일로 번역하는 것을 포함한다. 모든 디펜던시들의 규정이 다 만들어지고 나서 엔터티가 생성된다. 몇몇 아이템들 (일례로 데이터 파일들) 은 그들이 더 이상의 디펜던시들을 갖지 않는 엔드 포인트(end points)일 수 있다. 실행 파일과 같은, 다른 아이템들은, 그 아이템들로부터 생성되는 많은 디펜던시들을 가질 수 있다. 다음 티어의 선택을 위해, 엔터티들의 소정의 드레시홀드가 이미 위치되어 있으며 이 드레시홀드에 다다랐을 때에 커런트 티어의 처리가 종료될 수 있는 조건부 규정이 존재할 수 있다.

일단 커런트 티어의 모든 계수된 엔터티들이 분석되면, 프로세스는 처리를 위한 넥스트 티어를 선택한다 (스텝 37). 그리고 나서 프로세스는, 모든 티어의 처리를 완료하였는가 여부를 결정한다. 만약 아니라면, 스텝 38로부터 스텝 34로 되돌아가 루프를 돌면서 처리를 계속한다. 그렇지 않으면, 프로세스는 종료한다 (스텝 39).

이제 도 3을 언급하면, 스텝 24 (도 1) 가 더 상세히 보여진다. 아이템 디펜던시를 결정함에 있어, 프로세스는 먼저 하나 이상의 후보를 생성한다 (스텝 40). 후보 생성 프로세스는 대체로 현재 조사되고 있는 루트 아이템의 이진(binary) 분석에 의존한다. 후보들은, 실행 파일 내에서 발견된 스트링들을 분석함으로써 생성될 수 있다. 각 스트링은 하나의 후보를 나타낼 수 있다. 그러나, 상기 생성된 후보들은 인밸리드(invalid) 일수 있다. 예를들어, 그들은 파일로 명명될 수 있거나, 그들은 메타데이터에 대한 레퍼런스 또는 포인터일 수 있으며, 또는 그들은 커런트 엔터티와 시스템 상의 다른 아이템들 간의 디펜던시들의 관점에서 보았을 때 시시한 정보일 수 있다. 그래서, 상기 생성된 후보들은, 시스템 상의 다른 밸리드(valid)한 아이템들을 참조하지 않는 후보들 또는 이미 수립된 아이템들 간에 중복관계에 있는 후보들을 삭제함으로써, 불필요한 부분이 제거된다 (스텝 42). 다음, 그 후보들이 확인된다 (스텝 44). 스텝 44에서, 중요한 것으로 보이는 후보 분석을 통과한 아이템들이 확인되며, 그리하여 후보와 그 부모 아이템간에 링크가 실질적으로 만들어진다. 그 링크는, 메타메이터에 대한 레퍼런스 또는 파일에 대한 레퍼런스일 수 있으며, 또는 애플리케이션에 의해 필요로 되는 정보의 외부 조각에 대한 레퍼런스일 수 있다. 그 링크는 확인될 수 있으며, 만약 확인이 성공적이라면, 그들은 계속 진행하여 디펜던시 계층의 처리를 통과하는 아이템들이 된다. 후보의 분석 및 확인에 있어, 프로세스는, 커런트 후보가 대비되어질 아이템들 및 다른 후보들의 저장 풀(pool)을 액세스하고 참조한다.

스텝 46에서, 분석 및 확인의 종국적인 아이템들이 패키지화된다 (스텝 46). 패키징 프로세스는 엔터티에 속하는 특정 아이템을 식별하는 데에 필요한 정보를 기록한다. 아이템을 실질적으로 조사할 필요없이, 또다른 애플리케이션이 그 아이템에 관한 두드러진 특성을 결정하기에 충분한 정보가 있다. 파일명에 추가하여, 그 아이템이 아이템 패키징에서 확인된 후, 그 파일 및 파일 버전을 식별하는 파일 크기 정보 및 크로스-체크 정보가 더해진다. 패키징된 각 아이템에 대해, 스텝 46이 반복되어, 커런트 아이템 아래에 있는 아이템들을 디펜던시 트리(dependency tree)에 위치시킨다. 커런트 아이템 아래의 각 아이템에 대해, 어떤 더 이상의 후보 계층도 겪게 되지 않을 원소 레벨 계층이 발견될 때까지, 프로세스는 반복적으로 계속한다. 그 지점에서 프로세스는 종료한다 (스텝 48).

도 4는, 엔터티들을 그룹핑하고 그 엔터티들을 패키징하는 프로세스의 스텝 26 (도 1) 을 더 상세히 보여준다. 스텝 26 은, 처음에 엔터티들 간의 인터섹션이나 엔터티들의 콜렉션(collections)을 규정함으로써 엔터티간 관계를 규정한다 (스텝 50). 이 프로세스는, 상기 엔터티를 커런트 프로세싱 레벨에서 다른 엔터티들과 관계내에 위치시킨다. 일단 관계들이 발견되면, 관련 엔터티들은 함께 그룹핑될 수 있으며, 어떻게든 하나의 엔터티들로 형성된다. 혹은 택일적으로, 엔터티들은 그 엔터티들이 중복될 경우 삭제를 위해 표시되어질 수 있다. 그리고나서 이 엔터티들은 정해진 엔터티간 관계에 기하여 처리된다 (스텝 52). 일 측면에서, 엔터티들은, 그들의 디펜던시들 및 오퍼레이팅 시스템에 대한 종속성 혹은 더 높은 레벨 요구에 따라 처리된다. 예를들어, 그 지점에서 오퍼레이팅 시스템의 특정 버전에 대한 요구, 그 엔터티가 사용하는 특정 하드웨어, 디스크 공간의 관점에서 특정 파일 크기 요구, 혹은 다른 그러한 디펜던시들이 처리된다. 마지막으로, 그 엔터티들은, 이후 사용을 위해 적절하게 포맷팅된 파일 내로 위치된다 (스텝 54). 더욱이, 엔터티로 패키징될 필요가 있는 파일상의 정보 또는 더 계수되어야 할 정보가 모아져서 포맷팅된 파일 내로 위치된다. 따라서 포맷팅된 파일은, 개별적으로 동작될 수 있는 원소 데이터 (즉 메타데이터)를 나타내는 기본 아이템들의 집합이다. 바람직하게는, 포맷은, 애플리케이션 기능성의 유용한 서브셋을 나타내기 위해 확장가능한 포맷이다. 아이템들이, 타이핑되며, 더 이상의 조사 없이 만들어질 비교 결정을 위한 타입에 관한 충분한 정보를 포함한다. 아이템 정보를 캡쳐하는데 추가하여, 아이템들을 논리적으로 그룹화하기 위해 그리고 디펜던시들, 디스크립션들, 및 행정적인 오버헤드와 같은 추가 정보를 제공하기 위해, 포맷은 증가하는 정보 계층을 제공한다. 스텝 54 이후, 도 4 의 프로세스가 종료한다 (스텝 56).

계층적 포맷(70)의 그래픽 예가 도 5 에 보여진다. 포맷(70)은 엔터티 그룹들(80 및 90)에 대한 불변 상태를 저장한다. 엔터티 그룹 80 은 0개 혹은 1개의 정보 블록(82)을 갖는다. 엔터티 그룹 80 은 관련 엔터티들의 집합인 바, 그들 모두는, 정보 블록(82)에 기술된 바와 같이 유사한 엔터티 레벨 디스크립션 디펜던시들을 공유한다. 엔터티 80은 또한, 하나 이상의 엔터티 블록들(84-86)을 갖는다. 엔터티 블록 84 내지 86은 아이템 생성 단계인 스텝 24 동안에 만들어진 아이템들의 집합이다. 예를들어, 그들은 관련 실행 파일들이거나 상이한 형태의 관련 다큐먼트 파일들의 집합일 수 있다. 유사하게, 엔터티 90 은, 0개 혹은 1개의 정보 블록(92) 및 한개 이상의 엔터티 블록(94-96)을 갖는다. 포맷은 텍스트 베이스이거나, 이진 베이스이거나, 압축되었거나, 및/또는 암호화되었을 수 있다. 포맷의 실시예는 다음과 같을 수 있다:

[INFO "entity set label"]

key=value

key2=value2

:

[ENT "entity set label"]

itemtype=value1, value2, value3, value4, … itemtype2=v2, v3, v4…

…

본 실시예에서, 블록들은, 브라켓들과 하나의 블록형 및 하나의 블록 라벨로 나타내어진다. 임의 수의 라인 분리된 키 밸류 쌍들(line separated key value pairs)이, 각 블록을 따른다. 만약 상기 키가 아이템 형태로 인식된다면, 예상되는 수의 밸류들이 아이템 형태에 종속하는 동일 라인 상에서 요구된다. 세 개의 블록 형식들 (INFO, ENT, DEP) 이 사용된다. INFO 블록형은, 엔터티 세트에 관한 일반적인 정보 및 전체 파일에 관한 기술적 정보를 포함한다. ENT 블록형은, 다른 엔터티들 및/또는 아이템들의 집합을 포함하며, DEP 블록형은, key=value 쌍으로 나타내어지는 디펜던시들을 포함한다. 더욱이, 다섯개 이상의 아이템 형식들 (file, pefile, reg, ini, lnk) 이 사용될 수 있는 기본형들이다. "file" 형식은, 시스템 상의 임의의 파일에 관한 것이다. "pefile" 형식은, 포터블 실행가능(Portable Executable) 포맷으로 된 실행 파일들에 관한 것이다. "reg" 형식은, 윈도우즈 등록시 엔트리를 나타내는 메타데이터에 관한 것이다. "ini" 형식은, "ini" 스타일 지원 파일에서 엔트리를 나타내는 메타데이터에 관한 것이며, "lnk" 형식은, 또다른 파일에 대한 숏컷(shortcut)을 나타내는 이진 메타데이터 파일에 관한 것이다. 다른 형식들이 추가적인 데이터나 메타데이터를 기술할 수 있다.

이제 도 6 으로 돌아가서, 예시적인 데스크탑 구성(configuration)이 보여진다. 도 6에서, 데스크탑(500)은, 스펠 체크 애플리케이션(502), 워드 프로세싱 애플리케이션(504) 및 스프레드쉬트(spreadsheet) 애플리케이션(506)을 포함한다. 추가적으로, 쓰레기통(trash can: 510)이 데스크탑(500) 상에 보여진다. 데스크탑(500)은, 스텝 22 에서처럼 루트 엔터티들을 결정할 때, 티어들 중의 하나로서 보여진다. 그 티어에서, 스펠 체크 애플리케이션(502), 워드 프로세싱 애플리케이션(504), 스프레드쉬트 애플리케이션(506) 및 쓰레기통(510)에 걸쳐 계수를 행한다. 프로세스는 쓰레기통(510)을 비우게 되나, 나머지는 엔터티들이나 아이템 디펜던시들이 규정되는 것처럼 취급된다. 아이템 디펜던시 리스트가 애플리케이션들(502-506) 각각에 대해 생성된다. 그런다음 데스크탑이, 유저용 소프트웨어의 설치나 유지 시에 이후 사용을 위한 소정의 포맷 내의 엔터티로서 인코딩된다.

도 1 의 프로세스를 수행하는데 있어, 시스템은, 스펠체커 및 워드 프로세싱 애플리케이션(502 및 504)이 형식에 있어 유사한가 및 유사한 디펜던시들을 갖는가를 결정한다. 따라서, 그들은, 공통 딕셔너리 (즉, 시소러스(thesaurus))를 신뢰할 수 있다는 사실을 나타내는 정보 블록 내로 진입한다. 더욱이, 애플리케이션 502 및 504 는, 하나 이상의 오퍼레이팅 시스템 요구를 공유할 수 있다. 그리하여, 정보 블록 82 가 엔터티들(502-504)에 대해 생성된다. 따라서, 엔터티 그룹은 하나의 정보 블록(82) 및 두 개의 엔터티 블록들(84-86) (각각은 두 애플리케이션(502-504) 중의 하나를 나타낸다) 로 이루어지면서 만들어진다. 더욱이, 전체 엔터티 그룹(80)은 스프레드쉬트 애플리케이션(506)과, 그들이 유사한 위치에 존재한다거나 그들이 관련 엔터티들의 그룹이나 스위트(suite)를 구성하는 것과 같이 유사한 경로를 통해 액세스 가능하다는 점에서, 유사성을 갖는다. 그와같이, 애플리케이션들(502-506)은, 함께 패키지화되어 더 큰 엔터티 그룹을 만든다. 그후, 최종 패키지가 애플리케이션 502-504 를 포함하는 하나의 엔터티 그룹(80) 및 애플리케이션 506을 포함하는 또다른 엔터티 그룹 90으로 이루어진다. 패키지는, 컴퓨터의 설치, 동기, 백업, 복구, 분석 및 수리를 포함하는 다양한 애플리케이션들에 적합한 상태 정보를 포함한다.

이제 도 7-10을 언급하면, 마이크로소프트 윈도우즈 오퍼레이팅 시스템 상에서 동작하는 본 발명의 일 실시예가 도시된다. 도 7 은, 컴퓨터 상의 논리 엔터티들을 분석, 기술 및 복제하는 프로세스(99)를 보여준다. 먼저, 프로세스(99)는 하나 이상의 엔터티들을 추적한다 (스텝 100). 컴퓨터 시스템 상에서 엔터티들을 찾아낸 후에, 프로세스(99)는, 모든 엔터티들의 프로세싱을 완성했는가 여부를 체크한다(스텝 102). 하나 이상의 엔터티들이 여전히 처리되어야 하도록 남아있다면, 프로세스(99)는, 아이템을 생성한다 (스텝 104). 다음, 프로세스(99)는, 그 아이템이 분석되어져야 하는가 여부를 체크한다 (스텝 106). 만약 그렇다면, 프로세스(99)는, 하나 이상의 후보들을 생성한다 (스텝 108). 그리고나서 프로세스(99)는, 추가적인 후보들이 처리되어져야 하는지를 체크한다 (스텝 110). 만약 그렇다면, 프로세스(99)는, 그 후보들이 확인되어져야 하는가를 또한 체크한다 (스텝 113). 만약 확인이 수행되지 않았다면, 프로세스(99)는, 계속해서 후보들을 생성하기 위해 스텝 108로 되돌아가서 루프를 돈다. 반면, 스텝 113에서, 확인이 수행되었다면, 프로세스(99)는, 아이템 생성 프로세스를 계속하기 위하여 스텝 104로 되돌아가서 루프를 돈다.

스텝 106 또는 스텝 110 으로부터, 아이템이 분석되지 않았을 경우에 또는 후보들이 생성되지 않았을 경우에, 프로세스(99)는, 스텝 112 로 진행하여, 그곳에서 그것이 루트 아이템에 존재하는지 여부를 체크한다. 만약 그렇지않다면, 프로세스(99)는, 스텝 112 로부터 스텝 108 로 진행하여 후보 생성 프로세스를 계속한다. 반면, 프로세스(99)가 루트 아이템에 존재할 경우에, 루틴은 엔터티 추적 프로세스(99) 내의 다음 티어 상에서 동작한다.

스텝 102 로부터, 모든 엔터티들이 분석되었을 경우에, 프로세스(99)는, 스텝 120 으로 진행하여 스텝 104-113에서 전에 규정된 엔터티들을 크로스-참조한다. 프로세스(99)는, 엔터티들 상의 추가적인 오버헤드 프로세싱이 수행되어져야 하는가 여부를 결정한다 (스텝 122). 만약 그렇지 않다면, 엔터티는, 스텝 124에서 먼저 논의된 적절한 포맷을 사용하여 패키지화된다. 반면, 엔터티의 추가적인 프로세싱은 스텝 126에서 수행된다.

이제 도 8을 참조하면, 예시적인 엔터티 (이 경우에는 데스크탑 엔터티) 를 분석하는 프로세스(200)가 보여진다. 스텝 200에서, 프로세스는 처리될 필요가 있는 링크들을 체크한다. 하나 이상의 링크가 처리될 필요가 있다면, 프로세스는 먼저 마이크로소프트 윈도우 오퍼레이팅 시스템의 "시작 메뉴"와 결합된 파일들을 분석한다 (스텝 204). "시작 메뉴"와 결합된 데이터는, 유저에 의해 공통으로 사용되는 데이터 또는 소프트웨어에 관한 정보를 제공하며, 따라서 상태 규정 프로세스에 깊게 관련된다. 스텝 204로부터, 프로세스는, 추가적인 링크들이 여전히 처리되어져야 하는지 여부를 체크한다 (스텝 206). 그렇지않다면, 프로세스는, 모든 실행 파일들을 알려진 위치에 위치시킨다 (스텝 208). 추가적으로, 프로세스는, 추가적인 파일들이 여전히 처리되어져야 하는지 여부를 체크한다 (스텝 210). 그렇지않다면, 프로세스는, 위치설정된 파일들과 결합된 파일 확장 결합을 결정한다 (스텝 212). 스텝 212로부터, 프로세스는, 추가적인 확장(extensions)이 여전히 처리되어져야 하는지 여부를 체크한다 (스텝 214). 그렇지않다면, 프로세스는, 경로상의 실행 파일들을 결정한다 (스텝 216). 그후, 프로세스는, 임의의 다른 파일들이 여전히 처리되어져야 하는지 여부를 결정한다 (스텝 218). 그렇지않다면, 스텝 218로부터, 어떤 더 이상의 파일들도 처리되어져야할 필요가 없을 경우, 프로세스가 더 이상의 파일들이 여전히 처리되어져야 하는지 여부를 체크하기 (스텝 222) 전에, 글로벌 실행가능성이 결정된다 (스텝 220). 스텝 222 로부터, 만약 모든 파일들이 처리되어졌다면, 프로세스는 진행하여 엔터티 크로스 참조 리스트를 만든다 (스텝 224). 반면, 스텝 202, 206, 210, 214, 218 또는 222 로부터, 엔터티가 발견되지 않았다면, 프로세스는 스텝 226 으로 진행하여 그곳에서 그 엔터티가 처리되어졌는가 여부를 체크한다. 만약 그렇다면, 프로세스는 이전 상태로 리턴한다 (스텝 228). 한편으로는, 프로세스는 스텝 226으로부터 진행하여 스텝 230에서 아이템 생성을 수행한다.

이제 도 9를 참조하면, 아이템 생성 프로세스(230)가 더 상세히 보여진다. 먼저, 프로세스는, 아이템이 알려진 형식인가 여부를 체크한다 (스텝 232). 그렇지않다면, 아이템은 패키지화된다 (스텝 234). 반면, 아이템이 알려진 타입이라면, 프로세스는, 그 파일이 실행 파일인지 여부를 체크한다 (스텝 236). 만약 그렇다면, 프로세스는, 그 파일이 포터블 실행가능(PE) 포맷에 속하는지 여부를 결정한다 (스텝 238). PE 파일 포맷은 선형 스트림 데이터로 조직된다. 그것은, MS-DOS 헤더, 리얼-모드 프로그램 스터브(stub), 및 PE 파일 사인과 함께 시작한다. 바로 다음은, PE 파일 헤더 및 옵션 헤더이다. 그 위에, 모든 섹션 헤더가 나타나며, 모든 섹션 바디가 나타난다. 섹션들은, 코드, 데이터, 리소스(resources) 및 다른 실행가능 정보를 포함하여, 파일 내용을 포함한다. 각 섹션은 하나의 헤더와 하나의 바디 (로우(raw) 데이터) 를 갖는다. 섹션들은, 헤더가 데이터를 판독할 수 있는 충분한 정보로 채워져 있는 한, 링커가 그들을 조직하기를 원하는 거의 모든 임의의 방식으로 조직될 수 있다. 그 파일을 폐쇄하는 것은, 재배치 정보, 심볼 테이블 정보, 라인 넘버 정보 및 스트링 테이블 데이터를 포함하는 몇몇 잘못된 정보의 다른 영역이다. PE 파일 내의 정보는, 파일을 다루는 방법을 결정하기 위해 시스템이나 애플리케이션에 의해 사용되는 기본적으로 하이-레벨 정보이다. 제 1 필드는, DEC?? Alpha, MIPS R4000, Intel?? x86, 또는 몇몇 다른 프로세서와 같은, 어떤 형태의 머시인을 위해 익시큐터블(executable)이 만들어졌는가를 나타내는데 사용된다. 시스템은, 파일 데이터의 나머지로 좀더 진행하기 전에 그 파일을 처리하는 방법을 재빨리 결정하기 위해 이 정보를 사용한다.

스텝 238 로부터, 파일이 PE 파일인 경우에, 파일이 분석되며, 후보들이 생성된다 (스텝 240). 파일이 PE 파일이 아닌 경우에, 프로세스는 파일의 포맷이 실행가능한(exe) 이진 파일인가 여부를 체크한다 (스텝 242). 만약 그렇다면, 프로세스는, 이진 실행가능성의 분석을 수행하며, 또는 후보를 생성한다 (스텝 244).

반면, 스텝 242에서, 파일 포맷이 exe 이진 파일 포맷이 아니라면, 프로세스는, 진행하여 파일 포맷이 exe 스크립트 포맷인가 여부를 체크한다 (스텝 246). 만약 그렇다면, 스크립트 exe 파일의 분석 및 후보 생성이 수행된다 (스텝 248). 한편으로는, 프로세스는 스텝 246으로부터 진행하여 아이템을 패키지화한다 (스텝 250).

스텝 236에서, 포맷이 실행 파일 포맷이 아닌 경우에, 프로세스는, 파일 포맷이 정보 포맷인지 여부를 체크한다 (스텝 252). 만약 그렇다면, 정보 파일은 후보를 위해 생성된다 (스텝 254).

스텝 252에서, 파일 포맷이 정보 파일 포맷이 아닌 경우에, 프로세스는, 스텝 256으로 진행하여, 그곳에서 파일이 알려진 데이터 포맷에 속하는지 여부를 체크한다 (스텝 256). 만약 그렇다면, 프로세스는 데이터 파일 후보 생성을 수행한다 (스텝 258). 한편으로는, 프로세스는 스텝 256으로부터 진행하여 아이템을 패키지화한다 (스텝 234). 아이템이 스텝 232에서 알려진 형식이 아닌 경우에 스텝 234가 또한 수행된다.

이제 도 10을 참조하면, 아이템을 분석하는 프로세스가 보여진다. 도 10의 프로세서에 들어갈 때, 커런트 모듈이 모듈 형식과 같은 정보를 위해 스캔된다 (스텝 260). 모듈 스캔을 완료한 후, 프로세스는, 추가적인 모듈이 여전히 스캔되어져야할 필요가 있는지 여부를 결정한다 (스텝 262). 스텝 264에서, 그 형식이 알려지지 않았을 경우에, 프로세스는, 모듈 스캔 프로세스(260)를 반복적으로 콜(call)한다. 만약 그 형식이 알려져 있다면, 프로세스는, 스텝 266으로 진행하여, 그곳에서 모듈이 ODBC 타입에 속하는가 여부를 체크한다. 만약 그렇다면, 프로세스는 진행하여 적절한 모듈 플래그를 턴온한다 (스텝 268). 반면, 모듈이 ODBC 모듈이 아니라면, 프로세스는 진행하여 그 모듈이 등록 모듈인지 여부를 체크한다 (스텝 270). 만약 그렇다면, 적절한 모듈 플래그가 턴온된다 (스텝 268). 스텝 270으로부터, 그 모듈이 등록 모듈이 아닌 경우에, 프로세스는 진행하여 그 모듈이 COM 모듈인지 여부를 체크한다 (스텝 272). 만약 그렇다면, 프로세스는 스텝 268로 진행한다. 스텝 268로부터, 프로세스는 진행하여 스텝 276에서 아이템을 확인한다.

모든 모듈이 스텝 262에서 스캔된 경우에, 프로세스는 스트링 스캔 동작을 수행한다 (스텝 280). 다음, 프로세스는, 추가적인 스트링이 여전히 처리되어져야할 필요가 있는지 여부를 결정한다 (스텝 282). 만약 그렇다면, 스트링 매칭 동작이 수행된다 (스텝 284). 스트링 매칭 동작으로부터, 프로세스는, 스트링이 등록 형식에 속하는가 여부를 체크한다 (스텝 286). 만약 그렇다면, 등록 매칭 동작이 수행된다 (스텝 288). 스텝 286 또는 스텝 288로부터, 프로세스는, 그 스트링이 ODBC 형식인지 여부를 체크하도록 진행한다 (스텝 290). 만약 그렇다면, ODBC 매칭 동작이 수행된다 (스텝 292). 스텝 290 또는 스텝 292 로부터, 프로세스는, 그 스트링이 COM 형식인지 여부를 체크하도록 진행한다 (스텝 294). 만약 그렇다면, COM 매칭 동작이 스텝 296에서 수행된다. 스텝 294 또는 스텝 296으로부터, 프로세스는, 그 파일이 매치를 명명하는지 여부를 체크한다 (스텝 298). 만약 그렇다면, 아이템을 확인하기 위해 스텝 276 으로 진행하기 전에, 아이템이 시블링(sibling) 리스트(300)에 추가된다.

스트링 스캔이 스텝 282에서 모든 스트링에 대해 수행되어 왔을 경우에, 프로세스는 관련된 아이템들을 위치시키기 위해 시블링 스캔을 수행하도록 진행한다 (스텝 302). 다음, 그것은, 추가적인 파일이 여전히 스캔되어져야 하는가 여부를 결정한다 (스텝 304). 만약 그렇지 않다면, 그 아이템은 스텝 306에서 확인된다. 한편으로는, 아이템이 확인되기 전에, 시블링 매치 동작이 수행된다 (스텝 308).

상기 논의된 바와 같이, 애플리케이션 상태는, 유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하고, 상기 규정된 엔터티들에 종속하는 아이템들을 규정하고, 겹친 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 그룹핑하고, 소정의 포맷을 사용하는 엔터티들의 그룹을 패키징함으로써, 도달될 수 있다. 본 시스템은 커런트 머시인 상태에 기한 자동 관련성 분석을 제공하여, 기초 데이터, 메타데이터 및 컴퓨터 시스템의 설치, 동기, 백업, 분석 및 수리에 필요한 디펜던시들을 결정론적인 방식으로 계수한다.

여기에 기술된 기법은, 하드웨어 또는 소프트웨어, 또는 그들 양자의 조합으로 구현될 수 있다. 바람직하게는, 그 기법은, 각각이 프로세서, 프로세서에 의해 판독가능한 저장 매체 (휘발성 및 비휘발성 메모리 및/또는 저장 구성요소를 포함하여), 및 적절한 입출력 장치를 포함하는 프로그램가능 컴퓨터들 상에서 수행하는 컴퓨터 프로그램에서 구현된다. 프로그램 코드는, 기술된 기능들을 수행하기 위해 및 출력 데이터를 생성하기 위해 입력 장치를 사용하여 입력된 데이터에 인가된다. 출력 정보가 하나 이상의 출력 장치에 인가된다.

도 11은, CPU 버스 (640)에 결합된 CPU (610), RAM (620), 및 I/O 컨트롤러 (630)를 포함하는 컴퓨터 시스템(600)과 같은 것을 도시한다. I/O 컨트롤러(630)는 또한, I/O 버스에 의해 키보드(660) 및 마우스(670) 그리고 모니터(680)와 같은 출력 장치들에 접속된다. 여러 변형이 다음 청구범위의 범위 내에서 만들어진다. 예를들어, 입력 장치로서 마우스를 사용하는 대신, 압력 감지 펜이나 테블렛(teblet)이 커서 포지션 정보를 생성하는데 사용될 수 있다.

더욱이, 각 프로그램은, 바람직하기로는, 컴퓨터 시스템과 통신하는 하이 레벨 프로시저나 목적-지향 프로그래밍어로 구현된다. 그러나, 프로그램은, 원한다면, 어셈블리나 목적어로 구현될 수 있다. 임의의 경우에, 언어는 컴파일된 혹은 인터프리트된 언어일 수 있다.

각각의 그러한 컴퓨터 프로그램은, 바람직하게는, 기술된 프로시저들을 수행하기 위해 컴퓨터에 의해 저장 매체나 장치가 판독될 때 컴퓨터를 구성하고 동작시키기 위해, 범용 혹은 특수 목적의 프로그램가능 컴퓨터에 의해 판독가능한 저장 매체나 장치 (예를들어, CD-ROM, 하드 디스크, 또는 마그네틱 디스켓) 상에 저장된다. 시스템은 또한, 컴퓨터 프로그램으로 구성된 컴퓨터 판독가능 기록 매체로서 구현될 수 있는 바, 그렇게 구성된 저장 매체는 컴퓨터로 하여금 특정 및 미리 정해진 방식으로 동작하도록 한다.

본 발명이 일 실시예를 참조하여 보여지고 기술되었지만, 본 기술분야에서 통상의 전문가라면, 이상의 또는 다른 변형이, 다음의 청구범위의 기술사상과 범위를 벗어나지 않고, 형태상 또는 세부적으로, 만들어질 수 있다는 것을 이해할 수 있을 것이다.

Claims

유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하는 단계;

상기 규정된 엔터티들에 종속하는 아이템들을 규정하는 단계;

겹친 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 그룹핑하는 단계; 및

소정의 포맷을 사용하는 엔터티들의 상기 그룹을 패키징하는 단계를 포함하는, 애플리케이션의 상태를 규정하는 프로세스.
제 1 항에 있어서, 상기 엔터티들을 규정하는 단계는,

사용자 접근가능성(accessibility)의 티어(tier)들을 규정하는 단계;

각 티어에 대해, 소정의 기준에 기하여 루트 엔터티들을 계수하는 단계; 및

각 계수된 엔터티들에 대해, 상기 엔터티의 하나 이상의 디펜던시들을 규정하는 단계

를 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 아이템 디펜던시를 규정하는 단계는,

하나 이상의 후보들을 생성하는 단계;

상기 후보들을 분석하는 단계;

상기 후보들을 확인하는 단계; 및

상기 후보들과 결합된 아이템들을 패키징하는 단계

를 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 엔터티를 그룹핑하고 패키징하는 단계는,

엔터티 간 관련성(relationship)을 규정하는 단계; 및

상기 엔터티 간 관련성에 기하여 상기 엔터티들을 처리하는 단계

를 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 하나 이상의 영속적인 상태 표시자들(representations)을 생성하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 5 항에 있어서, 상기 영속적인 상태 정보는 포맷 내에 있고,

0개 또는 1개 정보 블록을 생성하는 단계; 및

1개 이상의 엔터티 블록들을 생성하는 단계

를 더 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 애플리케이션 상태는 완벽하고 연속적인 런-타임 정보를 제공하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 컴퓨터 시스템의 설치, 동기, 백업, 복구, 분석 및 수리 시에 상기 애플리케이션 상태를 인가하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 8 항에 있어서, 상기 컴퓨터 시스템은 윈도우즈 오퍼레이팅 시스템을 수행하는 것을 특징으로 하는 방법.
사용자 접근가능성의 티어(tier)들을 규정하는 단계, 각 티어에 대해, 소정의 기준에 기하여 루트 엔터티들을 계수하는 단계, 및 각 계수된 엔터티들에 대해, 상기 엔터티의 하나 이상의 디펜던시들을 규정하는 단계를 포함하는, 유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하는 단계;

하나 이상의 후보들을 생성하는 단계, 상기 후보들을 분석하는 단계, 상기 후보들을 확인하는 단계, 및 상기 후보들과 결합된 아이템들을 패키징하는 단계를 포함하는, 상기 디펜던시 아이템들을 규정하는 단계;

엔터티 간 관련성(relationship)을 규정하는 단계, 상기 엔터티 간 관련성에 기하여 상기 엔터티들을 처리하는 단계, 및 상기 엔터티들을 소정의 포맷 내에 두는 단계를 포함하는, 상기 규정된 루트 엔터티들을 그룹핑하고 소정의 포맷을 사용하는 상기 엔터티들을 패키징하는 단계;

를 포함하는,

윈도우즈 오퍼레이팅 시스템을 갖는 컴퓨터 시스템의 설치 , 동기, 백업, 복구, 분석 및 수리 시에 상기 애플리케이션 상태를 규정하는 방법.
유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하는 코드;

상기 규정된 엔터티들에 종속하는 아이템들을 규정하는 코드;

겹친 엔터티들을 잘라내고 유사한 엔터티들을 결합함으로써 엔터티들을 그룹핑하는 코드; 및

소정의 포맷을 사용하는 엔터티들의 상기 그룹을 패키징하는 코드를 포함하는, 애플리케이션의 상태를 규정하는 명령어들을 갖는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 상기 엔터티들을 규정하는 코드는,

사용자 접근가능성(accessibility)의 티어(tier)들을 규정하는 코드;

소정의 기준에 기하여 루트 엔터티들을 계수하는 각 티어 상에서 동작하는 코드; 및

상기 엔터티의 하나 이상의 디펜던시들을 규정하는 각 계수된 엔터티들 상에서 동작하는 코드

를 포함하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 상기 아이템 디펜던시를 규정하는 코드는,

하나 이상의 후보들을 생성하는 코드;

상기 후보들을 분석하는 코드;

상기 후보들을 확인하는 코드; 및

상기 후보들과 결합된 아이템들을 패키징하는 코드

를 포함하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 상기 엔터티 그룹핑 코드는,

엔터티 간 관련성(relationship)을 규정하는 코드; 및

상기 엔터티 간 관련성에 기하여 상기 엔터티들을 처리하는 코드

를 포함하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 하나 이상의 영속적인 상태 정보의 표시자들 (representations)을 생성하는 코드를 더 포함하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 15 항에 있어서, 상기 영속적인 상태 정보는 포맷 내에 나타나 있고,

0개 또는 1개 정보 블록을 생성하는 코드; 및

1개 이상의 엔터티 블록들을 생성하는 코드

를 더 포함하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 상기 애플리케이션 상태는 완벽하고 연속적인 런-타임 정보를 제공하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 11 항에 있어서, 상기 애플리케이션 상태는 컴퓨터 시스템의 설치, 동기, 백업, 복구, 분석 및 수리 시에 사용되는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
제 18 항에 있어서, 상기 컴퓨터 시스템은 윈도우즈 오퍼레이팅 시스템을 수행하는 것을 특징으로 하는 컴퓨터 판독가능 기록매체.
프로세서;

상기 프로세서에 결합된 메모리 어레이;

상기 프로세서에 결합된 디스플레이; 및

유저에 대한 소정의 기능성(functionalities)을 제공하는 엔터티들을 규정하는 코드, 상기 규정된 엔터티들에 종속하는 아이템들을 규정하는 코드, 겹친 엔터티들을 잘라내고 유사한 엔터티들을 그룹으로 결합하는 코드, 및 소정의 포맷을 사용하는 엔터티들의 상기 그룹을 패키징하는 코드를 포함하는, 애플리케이션의 상태를 규정하는 코드들을 갖는 컴퓨터 판독가능 기록매체를 포함하며, 상기 프로세서에 결합된 데이터 저장 장치;

를 포함하는 컴퓨터 시스템.