KR20170140359A - 주문형 리소스 - Google Patents

Abstract

소프트웨어 애플리케이션을 구축하기 위한 컴퓨터 구현 방법이 개시된다. 방법은: 복수의 애플리케이션 리소스를 생성하는 단계; 복수의 태그를 생성하는 단계; 태그들 중 하나를 복수의 애플리케이션 리소스의 각각에 적용하는 단계; 애플리케이션 리소스들의 태그들에 따라 애플리케이션 리소스들을 그룹화하여 적어도 두 자산 팩을 형성하는 단계 - 자산 팩들은 각각 자산 팩 내의 모든 애플리케이션 리소스들에 의해 공유되는 적어도 하나의 태그에 의해 식별될 수 있음 -; 및 자산 팩들의 각각의 위치 및 자산 팩들이 다운로드되는 순서를 포함하는 자산 팩 목록을 생성하는 단계를 포함한다.

Description

주문형 리소스

관련 출원들에 대한 상호 참조

본 출원은 2015년 6월 5일자로 출원된 미국 가출원 제 62/171,894호, 2015년 9월 22일자로 출원된 미국 특허 출원 제14/861,405호, 및 2015년 9월 22자로 출원된 미국 특허 출원 제14/861,885호의 이익을 주장하며, 상기 출원들은 모든 목적을 위하여 전체적으로 본 명세서에서 참조로서 포함된다.

기술분야

본 개시내용은 일반적으로 소프트웨어 애플리케이션을 구축하는 시스템 및 방법에 관한 것으로, 더 구체적으로는, 메인 애플리케이션 및 애플리케이션의 다른 리소스들로부터 분리될 수 있는 주문형 리소스(on demand resource)들을 이용하여 소프트웨어 애플리케이션을 구축, 배치, 실행, 및 업데이트하여 애플리케이션의 동작을 방해하지 않으면서 필요에 따라 동적으로 이 주문형 리소스들이 요청 및 제거될 수 있도록 하는 것에 관한 것이다.

컴퓨팅 디바이스, 특히 소형 모바일 디바이스는 애플리케이션들 및 데이터를 저장하기 위한 디스크 공간과 같은 리소스의 양이 제한될 수 있다. 애플리케이션이 컴퓨팅 디바이스에 설치될 때마다, 다른 용도에 이용가능한 저장 공간을 감소시킨다. 통상적으로, 각각의 애플리케이션은, 클라이언트 디바이스에 다운로드되고 설치될 수 있는 단일 앱 번들에 패킹된다. 단일 앱 번들은, 애플리케이션이 사용되는 주어진 시간에 앱 번들 전체가 필요하지 않더라도, 그것의 코드 및 데이터의, 전체가 아닌 경우, 대부분을 포함할 수 있다. 코드 및 데이터 중 일부는 절대 활용되지 않을 수 있지만, 그럼에도 불구하고, 애플리케이션이 클라이언트 디바이스에 남아있는 한 디바이스 상의 저장 공간을 차지할 수 있다. 이는 클라이언트 디바이스 상의 소중한 저장 공간의 비효율적인 사용이며 디바이스에 설치될 수 있는 애플리케이션의 수를 제한할 수 있다. 애플리케이션이, 심지어 모바일 디바이스 상에서 실행되도록 설계된 애플리케이션도 상당한 크기일 수 있음을 고려한다면, 애플리케이션이 디바이스에 설치될 때 그것들의 사용성에 부정적인 영향을 주지 않으면서 디스크 공간의 낭비를 최소화하도록 애플리케이션을 설계하고 구성하는 것이 바람직할 수 있다.

개시내용의 일 양태는 일반적으로 애플리케이션과 연관된 다양한 애플리케이션 리소스들(즉, 주문형 리소스들)이 따로 패키징되도록 인에이블하고, 이어서 애플리케이션의 사용을 방해하지 않으면서 그리고 필요에 따라 개별적으로 클라이언트 디바이스로부터 그것들이 설치 및 삭제되게 하는 소프트웨어 애플리케이션을 구축 및 배치하는, 시스템 및 방법에 관한 것이다. 설치 및 제거 프로세스는 백그라운드에서 일어나서 사용자에게 보이지 않을 수 있다. 이를 통해, 애플리케이션, 특히 상대적으로 대용량의 콘텐츠를 갖는 애플리케이션이 상당량의 저장 공간을 소모하지 않으면서 클라이언트 디바이스 상에 상주하고 동작할 수 있다. 결과적으로, 이를 통해 디바이스에 다른 애플리케이션 및 데이터를 더 많이 수용할 수 있도록 유연성을 제공할 수 있다. 그와 같이, 이는 종래의 애플리케이션에 비해 상당한 이익을 제공할 수 있는데, 그 이유는 종래의 애플리케이션은 통상적으로 모든 파일들의 전체 다운로드 및 설치를 요구하며, 그것들이 실제로 필요한지 여부에 상관없이 클라이언트 디바이스 상에 보관되어야하기 때문이다.

이에 비교적으로, 주문형 리소스로 구축되는 애플리케이션은 애플리케이션에 관련된 어떠한 사용자 경험의 희생 없이 동작할 디바이스 상의 일부의 저장 공간만을 요구할 수 있다. 초기에 설치되지 않은 주문형 리소스는 나중에, 바람직하게는 애플리케이션이 필요로 하기 전에 요청될 수 있다. 유사하게, 디바이스에 설치된 주문형 리소스 중 일부는 더 이상 필요하지 않고/않거나 디스크 공간이 부족할 때 제거될 수 있다. 본질적으로, 유한한 양의 디바이스의 디스크 공간의 최적의 활용을 달성하기 위하여, 애플리케이션의 수요에 기초하여, 애플리케이션과 연관된 다양한 애플리케이션 리소스들이 디바이스에서 교대로 사용될 수 있다.

개시내용의 다른 양태는 일반적으로 애플리케이션/클라이언트 디바이스의 수요(또는 예상 수요)에 기초하여 자동으로 주문형 리소스를 요청 및/또는 제거하는 것에 관한 것이다. 주문형 리소스로 구축된 애플리케이션의 경우, 특정 주문형 리소스가 필요할 가능성이 있는 시기를 예상할 수 있는 것이 중요할 수 있다. 이를 통해, 애플리케이션에 의해 호출되기 전에 페치됨으로써, 리소스가 다운로드될 때까지 사용자가 기다릴 필요가 없다. 이는 또한 잠재적인 런타임 오류의 발생을 방지할 수 있다. 저장 공간이 좁아지면 어떤 주문형 리소스가 제거될 수 있는지 아는 것도 또한 중요할 수 있다. 이 양태에서, 일부 실시예들은 주문형 리소스를 요청하기 위한 기준을 사전결정하거나 또는 동적으로 결정하는 방법을 개시한다. 다른 실시예들은 주문형 리소스 제거가 요청되면 제거할 디바이스의 기존 주문형 리소스를 식별 및/또는 순위결정하는 방법을 개시한다.

개시내용의 또 다른 양태는 일반적으로 주문형 리소스로 애플리케이션을 구축하도록 설계되고 클라이언트 디바이스 상의 애플리케이션들의 동작을 용이하게 하는 애플리케이션 프로그램 인터페이스(API) 및 기타 소프트웨어 개발 툴에 관한 것이다.

도 1은 개시내용의 실시예에 따른, 주문형 리소스를 이용한 애플리케이션의 구성을 예시하는 블록도이다.
도 2는 개시내용의 실시예에 따른, 주문형 리소스를 이용하여 애플리케이션을 구성하는 방법의 예시적인 단계들을 예시한다.
도 3은 개시내용의 실시예에 따른, 디바이스 상의 하나 이상의 애플리케이션의 애플리케이션 리소스를 관리하는 클라이언트 디바이스의 예시적인 모듈들 및 그것들의 상호작용을 예시한다.
도 4는 개시내용의 실시예에 따른, 클라이언트 디바이스 상에서 주문형 리소스를 이용하여 애플리케이션을 설정 및 실행하는 예시적인 단계들을 예시한다.
도 5는 개시내용의 실시예에 따른, 클라이언트 디바이스로부터 애플리케이션 리소스를 제거하는 예시적인 단계들을 예시한다.
도 6은 개시내용의 실시예에 따른, 애플리케이션을 주문형 리소스를 이용하여 새로운 버전으로 업데이트하는 예시적인 단계들을 예시한다.
도 7은 개시내용의 일부 실시예들에 사용될 수 있는 예시적인 API 아키텍처를 예시하는 블록도이다.
도 8은 개시내용의 실시예들에 따른 시스템의 컴포넌트들 간의 예시적인 상호작용을 예시하는 다이어그램이다.

예시 실시예들의 다음 설명에서, 첨부된 도면들이 참조되며, 실시될 수 있는 특정 실시예들이 도면들 내에서 예시로써 도시된다. 다양한 실시예들의 범위를 벗어나지 않으면서 다른 실시예들이 이용될 수 있고, 구조적 변경이 가해질 수 있다는 것이 이해되어야 한다.

본 명세서에 사용된 바와 같이, 용어 "디바이스" 및 "클라이언트 디바이스"는 하나 이상의 소프트웨어 애플리케이션을 실행할 수 있는 임의의 전자 디바이스들을 지칭하는 데 상호교환적으로 사용될 수 있다. 그러한 디바이스들은, 개인용 컴퓨터(PC), 맥(Mac), 데스크톱 및 랩톱 PC, 태블릿 PC, 스마트폰 및 기타 유형의 셀룰러 폰, 웨어러블 디바이스, 셋톱 박스, 스마트 TV, 디지털 미디어 플레이어, 및 차내 엔터테인먼트 시스템을 포함할 수 있지만 이에 한정되지 않는다. 본 명세서에 사용된 바와 같이, 용어 "저장 공간", "디스크 공간" 및 "저장 매체"는 클라이언트 디바이스 상의 임의의 유형의 저장장치를 지칭하는 데 상호교환적으로 사용될 수 있다. 저장 공간은 내부적(예컨대, 메모리, 하드 드라이브, 플래시 드라이브, 및 캐시 저장장치)이거나 아니면 외부적(예컨대, 클라우드 저장장치)일 수 있다. 용어 "소프트웨어 애플리케이션", "애플리케이션", 및 "앱"은 디바이스에 설치되고 실행될 수 있는 임의의 컴퓨터 프로그램을 지칭하는 데 상호교환적으로 사용될 수 있다.

용어 "애플리케이션 리소스"(또는 "리소스")는 애플리케이션과 연관된 임의의 데이터(또는 콘텐츠)를 지칭할 수 있다. 일 실시예에서, 애플리케이션 리소스는 애플리케이션을 실행하기 위한 소프트웨어 코드(또는 프로그램)를 배제할 수 있다. 소프트웨어 코드 또는 프로그램은, 예를 들어, 실행 파일들, 함수, 및 라이브러리들을 포함할 수 있다. 애플리케이션 리소스의 예들은, 이미지, 텍스트, 오디오, 및 비디오 파일들(즉, 소프트웨어 코드 아닌 임의의 파일)을 포함할 수 있지만, 이에 한정되지 않는다. 다른 실시예에서, 애플리케이션 리소스는 또한 애플리케이션을 실행하기 위한 소프트웨어 코드 중 적어도 일부를 포함할 수 있다. 용어 "자산 팩(asset pack)"은 적어도 하나의 공통적인 특성을 공유하는 하나 이상의 애플리케이션 리소스의 집합을 지칭할 수 있다. 용어 "앱 시작 번들(app start bundle)"은 1차 시기에 클라이언트 디바이스에서 애플리케이션을 시작하는 데 필요한 코드의 번들 및 선택적으로 다수의 애플리케이션 리소스들을 지칭할 수 있다. 앱 시작 번들 내의 코드 및 리소스는 애플리케이션을 기동시키고, 애플리케이션의 디폴트 화면을 디스플레이하는 것과 같은 애플리케이션의 대부분의 기본 기능들을 수행하는 데 필요하다.

용어 "주문형 리소스"는 애플리케이션의 실행을 방해하지 않고 동적으로 요청 및 제거될 수 있는 하나 이상의 애플리케이션 리소스를 지칭할 수 있다. 이 주문형 리소스는 앱 시작 번들에 포함되지 않은 리소스를 포함할 수 있다(예컨대, 앱이 실행되고 있을 때 앱의 요청에 의해 다운로드될 수 있는 자산 팩들 내의 리소스). 추가적으로 또는 대안적으로, 그것들은 앱 시작 번들의 일부이지만 더 이상 필요하지 않으면 제거될 수 있는 리소스를 포함할 수 있다. 추가적으로 또는 대안적으로, 그것들은 초기 앱 및 주문형 리소스(ODR) 설치 이후에, 또는 앱이 기동되기 전이라도 설치되도록 선택되는 자산 팩들 내의 리소스를 포함할 수 있다. 주문형 리소스는 데이터 및/또는 코드를 포함할 수 있다. 주문형 리소스는 애플리케이션이 컴파일될 때 하나 이상의 자산 팩으로 그룹화될 수 있지만, 앱 시작 번들과는 따로 저장되어서 애플리케이션이 처음 요청될 때 클라이언트 디바이스에 초기 다운로드되는 부분의 일부가 아닐 수 있다. 대신, 주문형 리소스를 갖는 자산 팩들은 필요에 따라 애플리케이션의 설치 이후에 개별적으로 요청될 수 있다. 설치가 되면, 그것들은 애플리케이션에 통합되어 그것들의 의도된 기능들을 수행할 수 있다. 그것들이 더 이상 애플리케이션이 필요로 하지 않고/않거나 클라이언트 디바이스 상에 공간이 부족하면, 주문형 리소스는 개별적으로 사전결정된 순서대로(예컨대, 무엇이 가장 덜 필요할지 결정하는 데 사용되는 경험에 기초한 순서) 애플리케이션의 실행을 방해하지 않으면서 디바이스에서 제거될 수 있다. 일부 구현예들에서, 특정 주문형 리소스들은 제거되고 다른 주문형 리소스들은 제거되지 않는다.

용어 "서버" 또는 "원격 서버"는 일반적으로 자신의 앱 시작 번들, 자산 팩, 및/또는 다른 리소스를 포함하는 애플리케이션들이 획득될 수 있는 하나 이상의 컴퓨터를 지칭하는 데 상호교환적으로 사용될 수 있다. 서버는 임의의 유형의 공지된 네트워크를 통해 하나 이상의 클라이언트 디바이스에 연결될 수 있다.

개시내용의 일 양태는 일반적으로 애플리케이션과 연관된 다양한 애플리케이션 리소스들(즉, 주문형 리소스들)이 따로 패키징되도록 인에이블하고, 이어서 애플리케이션의 사용을 방해하지 않으면서 개별적으로 클라이언트 디바이스로부터 그것들이 설치 및 삭제되게 하는 소프트웨어 애플리케이션을 구축 및 배치하는, 시스템 및 방법에 관한 것이다. 설치 및 제거 프로세스는 백그라운드에서 일어나서 사용자에게 보이지 않을 수 있다. 이를 통해, 애플리케이션, 특히 상대적으로 대용량의 콘텐츠를 갖는 애플리케이션이 상당량의 저장 공간을 소모하지 않으면서 클라이언트 디바이스 상에 상주하고 동작할 수 있다. 결과적으로, 이를 통해 디바이스에 다른 애플리케이션 및 데이터를 더 많이 수용할 수 있도록 유연성을 제공할 수 있다. 그와 같이, 이는 종래의 애플리케이션에 비해 상당한 이익을 제공할 수 있는데, 그 이유는 종래의 애플리케이션은 통상적으로 모든 파일들의 전체 다운로드 및 설치를 요구하며, 그것들이 실제로 필요한지 여부에 상관없이 클라이언트 디바이스 상에 보관되어야하기 때문이다.

이에 비교적으로, 주문형 리소스로 구축되는 애플리케이션은 애플리케이션에 관련된 어떠한 사용자 경험의 희생 없이 동작할 디바이스 상의 일부의 저장 공간만을 요구할 수 있다. 초기에 설치되지 않은 주문형 리소스는 나중에, 바람직하게는 애플리케이션이 필요로 하기 전에 요청될 수 있다. 유사하게, 디바이스에 설치된 주문형 리소스 중 일부는 더 이상 필요하지 않고/않거나 디스크 공간이 부족할 때 제거될 수 있다. 본질적으로, 유한한 양의 디바이스의 디스크 공간의 최적의 활용을 달성하기 위하여, 애플리케이션의 수요에 기초하여, 애플리케이션과 연관된 다양한 애플리케이션 리소스들이 디바이스에서 교대로 사용될 수 있다. 또한 애플리케이션이 사용될 수 있기 전에 전체 애플리케이션이 다운로드될 필요가 없기 때문에, 애플리케이션의 다운로드 시작과 애플리케이션의 기동 사이의 시간이 극적으로 단축될 수 있다.

개시내용의 다른 양태는 일반적으로 애플리케이션/클라이언트 디바이스의 수요(또는 예상 수요)에 기초하여 자동으로 주문형 리소스를 요청 및/또는 제거하는 것에 관한 것이다. 주문형 리소스로 구축된 애플리케이션의 경우, 특정 주문형 리소스가 필요할 가능성이 있는 시기를 예상할 수 있는 것이 중요할 수 있다. 이를 통해, 애플리케이션에 의해 호출되기 전에 페치됨으로써, 리소스가 다운로드될 때까지 사용자가 기다릴 필요가 없다. 이는 또한 잠재적인 런타임 오류의 발생을 방지할 수 있다. 저장 공간이 좁아지면 어떤 주문형 리소스가 제거될 수 있는지 아는 것도 또한 중요할 수 있다. 이 양태에서, 일부 실시예들은 주문형 리소스를 요청하기 위한 기준을 사전결정하거나 또는 동적으로 결정하는 방법을 개시한다. 다른 실시예들은 주문형 리소스 제거가 요청되면 제거할 디바이스의 기존 주문형 리소스를 식별 및/또는 순위결정하는 방법을 개시한다.

개시내용의 또 다른 양태는 일반적으로 주문형 리소스로 애플리케이션을 구축하도록 설계되고 클라이언트 디바이스 상의 애플리케이션들의 동작을 용이하게 하는 애플리케이션 프로그램 인터페이스(API) 및 기타 소프트웨어 개발 툴에 관한 것이다.

다음 단락은 주문형 리소스를 이용하여 소프트웨어 애플리케이션을 구축 및 배치하는 다양한 실시예들에 대하여 논의한다. 단일 애플리케이션 번들 내에 애플리케이션과 연관된 모든 리소스들(예컨대, 데이터, 콘텐츠, 및/또는 코드)을 포함하는 대신에, 일 실시예의 예시적인 애플리케이션은 다수의 자산 팩들로 그룹화되는 그것의 애플리케이션 리소스들로 구축될 수 있는데, 이것들은 컴파일 당시에는 모두 애플리케이션의 일부이지만, 애플리케이션의 나머지 부분과 별도로 자신들만 다운로드될 수 있다.

위에서 정의된 바와 같이, 애플리케이션 리소스는 애플리케이션과 연관된 임의의 데이터(또한 콘텐츠라고 지칭됨) 및/또는 코드를 포함할 수 있다. 일 실시예에서, 각각의 데이터(또는 콘텐츠) 파일은 하나의 애플리케이션 리소스에 대응할 수 있다. 다른 실시예에서, 동일한 디렉토리 내에 있는 파일들과 같은 다수의 파일들은 하나의 애플리케이션 리소스를 구성할 수 있다. 애플리케이션 리소스 중, 애플리케이션의 동작 동안 소정 단계에서만 필요한 일부 애플리케이션 리소스가 주문형 리소스로 특징지어질 수 있다. 주문형 리소스는 통상적으로 애플리케이션을 기동시키는 데 필요하지 않다. 애플리케이션 리소스는 대개 일 특정 애플리케이션과 연관될 수 있지만, 다수의 애플리케이션들과 공유될 수 있다.

도 1은 개시내용의 실시예에 따른, 주문형 리소스를 이용한 예시적인 애플리케이션의 구조를 예시한다. 애플리케이션(100)은 다수의 파일들(102, 104, 106, 110, 112, 116, 118, 120, 124)을 포함할 수 있다. 이 파일들은 상이한 유형들일 수 있다. 파일들 중 일부는 코드일 수 있고, 다른 것들은 데이터(예컨대, 이미지, 비디오, 텍스처 파일들, 음악, 및 음향 효과)를 포함할 수 있다. 이 예에서, 각각의 데이터 파일은 하나의 애플리케이션 리소스에 대응할 수 있다. 애플리케이션(100)은 개발자에게 제공되는 API 및 기타 소프트웨어 개발 툴들(아래에 상세하게 논의됨)을 이용하여 구축될 수 있다. 툴들 중 하나를 통해 애플리케이션의 개발자는 태그들의 수를 정의할 수 있다. 태그들은 개발자의 의도대로 임의적으로 식별될 수 있다. 임의의 수의 태그들이 애플리케이션에 대하여 생성될 수 있다. 바람직하게는, 각각의 태그(또는 태그들의 조합)는 하나의 공통적인 특성에 따라 애플리케이션 리소스들의 세트를 연관시키기는 데 사용될 수 있다. 다시 말해서, 태그들의 세트에서 각각의 태그(또는 태그들의 조합)의 값은 다수의 애플리케이션 리소스들의 논리적 그룹에 배정된 식별자에 대응할 수 있다.

예를 들어, 도 1의 애플리케이션(100)은 플레이어가 다음 레벨로 이동하기 전에 하나의 레벨을 완수하도록 요구하는 다중 레벨 비디오 게임일 수 있다. 게임의 각각의 레벨에 대하여 해당 레벨에 필요한 애플리케이션 리소스들을 지정하는 태그가 생성될 수 있다. 예를 들어, 파일들(102, 104, 106)은 레벨 1의 가상 환경을 렌더링하는 데 필요한 이미지 파일들일 수 있다. 이 파일들은 레벨 1에 필요한 애플리케이션 리소스들일 수 있다. 그와 같이, 그것들에는 "레벨 1" 태그가 적용될 수 있다. 유사하게, 파일들(110, 112)에는 "레벨 2" 태그가 적용되고, 파일들(116, 118, 120, 122)에는 "레벨 3" 태그가 적용될 수 있다. 다른 리소스는 레벨 독립적이지만, 몇몇 다른 식별가능한 특성들을 소유할 수 있고, 그에 따라 태그를 붙일 수 있다. 동일한 태그가 상이한 애플리케이션 리소스들에 적용될 수 있고 각각의 애플리케이션 리소스가 둘 이상의 태그와 연관될 수 있음을 이해해야 한다. 예를 들어, 이미지들 중 하나는 레벨 1 및 레벨 2 둘 모두에서 나타날 수 있어서 "레벨 1" 및 "레벨 2" 두 태그를 붙일 수 있다. 이것을 이용하여 상이한 레벨에 대하여 동일한 애플리케이션 리소스를 중복해서 만드는 것을 피할 수 있다.

애플리케이션 리소스들(또는 파일들)에 태그를 붙인 뒤, 공통 태그(또는 태그들)를 공유하는 것들은 자산 팩 내에 배치될 수 있다. 예를 들어, 도 1에 예시된 바와 같이, 자산 팩(108)은 파일들(102, 104, 106)을 포함할 수 있고, 게임의 레벨 1에 요구되는 애플리케이션 리소스들의 집합을 구성할 수 있다. 자산 팩(114)은 "레벨 2" 애플리케이션 리소스인, 두 파일(110, 112)을 포함할 수 있다. 유사하게, 자산 팩(124)은 게임의 "레벨 3" 리소스인, 파일들(116, 118, 120, 122)을 포함할 수 있다. 자산 팩들(108, 114, 124) 중 하나 이상의 애플리케이션 리소스는 주문형 리소스일 수 있고, 그것들 중 일부는(예컨대, 자산 팩들(114, 124)) 애플리케이션이 처음 클라이언트 디바이스에 의해 요청될 때 초기 다운로드 패키지(앱 시작 번들)의 일부가 아닐 수 있다.

또한, 게임이 기동될 때마다 게임의 기본 기능들을 수행하도록 요구되는 애플리케이션 리소스들(132, 134, 136)을 포함하는 기본 리소스 팩(130)이 있을 수 있다. 예를 들어, 기본 리소스 팩(130)은, 예를 들어, 게임의 오프닝 장면, 게임의 다양한 메뉴 및 옵션 설정, 사용자에 의해 선택되고 제어될 수 있는 적어도 하나의 아바타, 및 게임에서 사용자의 진행에 상관없이 게임 전체에 걸쳐 활용되는 임의의 다른 리소스들을 포함할 수 있다. 즉, 이 리소스들(132, 134, 136)은 게임의 임의의 레벨에만 특정한 것은 아니다. 또한, 게임은 게임을 기동시키고 게임의 다양한 동작들을 수행하기 위한 (예컨대, 실행가능한) 소프트웨어 코드인 파일들(142, 144, 146)을 또한 포함할 수 있다. 이 파일들은 앱 시작 번들에 포함될 수 있다(자산 팩에서는 배재됨). 다른 실시예들에서, 다수의 태그들을 공유하는 애플리케이션 리소스들은 하나의 태그만을 공유하는 리소스들과 유사한 방식으로 유사하게 자산 팩을 형성할 수 있다.

도 1의 자산 팩들은 단지 몇몇 예시적인 애플리케이션 리소스들을 포함하는 것으로 도시되지만, 각각의 자산 팩은 임의의 수의 애플리케이션 리소스들을 포함할 수 있음을 이해해야 한다. 또한, 애플리케이션은 임의의 수의 자산 팩들을 포함할 수 있다. 자산 팩들의 각각은 자산 팩 내의 리소스가 요구되면 애플리케이션에 의해 개별적으로 요청될 수 있다. 이를 통해 자산 팩들은 애플리케이션의 초기 설치 이후에 필요에 따라 다운로드 및 설치(또는 제거)될 수 있다.

도 2는 개시내용의 실시예에 따른, 주문형 리소스를 이용하여 애플리케이션을 구성하는 방법의 예시적인 단계들을 예시한다. 우선, 개발자는 애플리케이션을 함께 구성하는 애플리케이션 리소스들 및 코드의 라이브러리를 생성할 수 있다(단계(201)). 이어서, 개발자는 태그들의 세트를 정의하고 그것들을 다양한 애플리케이션 리소스들에 적용할 수 있다(단계(202)). 애플리케이션 리소스들에 태그를 붙인 이후에, 개발자는 자산 팩들을 구축할 수 있다(단계(203)). 각각의 자산 팩은 적어도 하나의 공통적인 태그(또는 태그들의 조합)를 공유하는 하나 이상의 애플리케이션 리소스를 포함할 수 있다. 이를 통해 각각의 자산 팩은 자산 팩 내의 애플리케이션 리소스들과 연관된 공통 태그(또는 태그들의 조합)에 의해 식별될 수 있다. 다시 말해서, 태그(또는 태그들의 조합)는 자산 팩들의 식별자로서 사용될 수 있다. 이는 또한 애플리케이션이 특정 태그(또는 태그들의 조합)와 연관된 자산 팩들을 요청하도록 인에이블할 수 있다. 일 실시예에서, 각각의 애플리케이션 리소스는 정확히 하나의 자산 팩을 차지할 수 있다. 태그들을 정의하는 단계, 그것들을 다양한 애플리케이션 리소스들에 적용하는 단계, 및 자산 팩들을 구축하는 단계들 중 하나 이상은 Xcode와 같은 임의의 적합한 소프트웨어/애플리케이션 개발 툴을 이용하여 구현될 수 있다.

자산 팩들이 구축되면, 자산 팩 내의 애플리케이션 리소스들은 호출 시 애플리케이션에 의해 액세스될 수 있는 포맷일 수 있다. 도 1에 예시된 바와 같이, 자산 팩들은 크기가 상이할 수 있다(즉, 자산 팩의 크기 또는 애플리케이션 리소스들이 구성되는 방법에는 제한이 없음). 다른 실시예들에서, 각각의 자산 팩은 소정 크기 제한을 갖도록 요구될 수 있다. 이 제한들은 자산 팩들을 서버에서 클라이언트 디바이스로 전송하기 위한 네트워크 대역폭 요구조건을 예측하고, 이 자산 팩들을 저장하기 위한 클라이언트 디바이스 상의 디스크 공간의 양을 예상하는 데에도 도움을 줄 수 있다.

도 2를 다시 참조하면, 자산 팩들이 구축될 때 두 리스트, 즉, 주문형 리소스 리스트 및 자산 팩 목록이 또한 생성될 수 있다(단계(204)). 이 실시예에서, 이 두 리스트는 속성 리스트 파일들(예컨대, 파일명 확장자.plist를 갖는 p-리스트 파일들)로서 생성될 수 있다. 그러나, 그것들은 임의의 적합한 파일 포맷일 수 있음을 이해해야 한다. 주문형 리소스 리스트는 다양한 애플리케이션 리소스들의 각자의 자산 팩에 대한 맵핑을 제공할 수 있다. 애플리케이션 리소스들의 각각은 이미 태그가 붙어있기 때문에, 주문형 리소스 리스트는 또한 자산 팩들의 각각과 연관된 태그(또는 태그들의 조합)를 식별할 수 있다. 서버는 주문형 리소스들에 대한 요청의 일부로서 하나 이상의 태그를 수신할 때, 주문형 리소스 리스트를 이용하여 자산 팩들을 식별할 수 있다. 예를 들어, 주문형 리소스 리스트는 클라이언트 디바이스로부터 "레벨 2" 태그를 갖는 요청을 수신할 때 레벨 2 자산 팩들을 식별할 수 있다.

자산 팩 목록은 각각의 요청된 자산 팩이 다운로드될 수 있는 네트워크 상의 어드레스를 나타낼 수 있다. 일 실시예에서, 자산 팩 목록 내의 어드레스는 자산 팩들의 위치를 명시하는 URL(uniform resource locator)의 리스트를 포함할 수 있다. 다른 실시예들에서, 자산 팩 목록 내에 명시되는 위치들은, 예를 들어, IP 어드레스, 서버 어드레스, 도메인 이름, 디렉토리 이름 등을 포함할 수 있다. 본질적으로, 자산 팩 목록은 애플리케이션과 그것의 자산 팩들 사이의 단서 역할을 할 수 있다. 추가적으로, 자산 팩 목록은 또한 각각의 자산 팩과 연관된 다양한 속성들을 명시하는 메타데이터를 포함할 수 있다. 예를 들어, 메타데이터는 자산 팩의 크기 및 그것들이 애플리케이션에 의해 페치될 선호 순서를 포함할 수 있다. 추가적으로 또는 대안적으로, 메타데이터는 소정 자산 팩들을 다운로드하기 전에 충족되는 조건들을 나타낼 수 있다(예컨대, 처음에 레벨 1, 이어서 레벨 2, 그 다음 레벨 3과 같은 자산 팩들의 다운로드 순서). 아래에 상세하게 논의되는 바와 같이, 자산 팩 목록은 또한 자산 팩의 버전을 검증하고 새로운 버전이 다운로드될 필요가 있는지 결정하는 데 사용될 수 있는 콘텐츠 해시를 포함할 수 있다. 일 실시예에서, 자산 팩 목록은 애플리케이션의 초기 다운로드에 포함되지 않고 개별적으로 요청되고 규칙적으로 갱신되어, 애플리케이션이 그것이 요청하고 있는 자산 팩들을 얻을 수 있도록 자격을 부여받고 또한 올바른 자산 팩들이 애플리케이션에 배포되도록 보장한다. 애플리케이션이 앱 스토어에서 호스트될 때 자산 팩 목록을 앱 시작 번들과 별개로 다운로드되도록 요구하는 것이 선호된다. 다른 실시예에서, 자산 팩 목록이 애플리케이션 내에 포함되지 않지만, 자산 팩 목록에 대한 URL은 앱 시작 번들의 일부로서 설치 목록에 삽입될 수 있다. URL은 프리페치된 주문형 리소스들과 함께 애플리케이션의 초기 설치를 지원할 수 있다. 이 실시예는 자산 팩 목록이 지속적 통합 서버 또는 내부 엔터프라이즈 서버 상에 호스트될 때 선호될 수 있다. 다른 실시예에서, 자산 팩 목록은 ODR 애플리케이션에 내장되거나 클라이언트 디바이스에 다운로드될 수 있다. 자산 팩 목록은 또한 랜덤 웹 서버가 자산 팩들을 호스트할 때 애플리케이션에 내장될 수 있다. 또 다른 실시예에서, URL을 구비한 완성된 자산 팩 목록이 아닌 자산 팩 목록의 템플릿이 애플리케이션에 내장될 수 있다. 이 구성은 애플리케이션이 처음 다운로드될 때 실제 URL(또는 주문형 리소스들의 다른 유형의 어드레스)이 아직 완결되지 않은 경우 선호될 수 있다. 템플릿은 향후 URL이 완결되면 업데이트될 수 있다.

도 2는 주문형 리소스 리스트 및 자산 팩 목록을 생성하는 단계(단계(204))가 자산 팩들을 생성하는 단계(단계(203)) 이후에 이어지는 것을 도시하지만, 이 단계들은 자산 팩들이 구축되어 감에 따라 리스트가 생성될 때 동시에 일어날 수 있음을 이해해야 한다. 일 실시예에서, 단계들(201 내지 204)은 애플의 Xcode와 같은 통합 개발 환경(IDE)에서 수행될 수 있다.

자산 팩들, 주문형 리소스 리스트, 및 자산 팩 목록이 생성된 이후에, 그것들은 애플리케이션의 나머지 부분(예컨대, 앱 시작 번들)과 함께 서버 상의 아카이브에 배치될 수 있고, 애플리케이션은 다운로드 가능하게 만들어질 수 있다(단계(205)).

일 실시예에서, 애플리케이션 및 연관된 자산 팩들이 서버로부터 도착하면, 그것들은 개별적으로 코드 서명으로 서명될 수 있다. 하나의 자산 팩의 코드 서명이 애플리케이션의 나머지 부분의 서명과 매치되지 않는 경우, 자산 팩이 위조되었고 교체가 필요하다고 결정될 수 있다. 추가적으로 또는 대안적으로, 애플리케이션이 앱 스토어에서 제공되고 있는 경우, 자산 팩들 및 애플리케이션의 나머지 부분은 앱 스토어 서명으로 서명될 수 있는데, 이는 애플리케이션이, 예를 들어, 개발자가 직접 제공한 것이 아니라 앱 스토어에서 제공됨을 나타낼 수 있다.

위에서 언급한 바와 같이, 종래의 애플리케이션은 통상적으로 그것의 애플리케이션 리소스들(예컨대, 코드 및 데이터)의 전부가 아닌 경우 대부분을 포함하는 단일 번들의 형태로 다운로드 된다. 단일 앱 번들을 풀어 클라이언트 디바이스에 애플리케이션을 설치할 수 있다. 설치 프로세스는 통상적으로 애플리케이션 리소스들을 앱 번들에서 클라이언트 디바이스의 저장 공간으로 복사하는 단계를 수반한다. 성공적인 설치 이후에, 애플리케이션은 자신의 지정된 기능을 수행하도록 기동될 수 있다. 보통, 모든 애플리케이션 리소스들이 애플리케이션이 실행되고 있는 모든 시간에 활용되는 것은 아니다. 그럼에도 불구하고, 그것들은 애플리케이션이 디바이스에서 삭제되지 않는 한 클라이언트 디바이스 상의 저장 공간의 일부분을 차지할 수도 있다. 대형 애플리케이션들은 클라이언트 디바이스, 특히 공간의 크기가 제한된 디바이스 상의 저장 공간의 상당 부분을 차지할 수 있다. 종래의 애플리케이션을 삭제하여 디스크 공간을 해방시킬 때, 전체 애플리케이션이 제거되어야 한다.

대조적으로, 본 개시내용의 실시예들에서, 애플리케이션 리소스는 위에서 논의한 바와 같이 다수의 자산 팩들로 그룹화될 수 있다. 자산 팩들 중 하나 이상은 앱 시작 번들에 포함될 수 있다. 클라이언트 디바이스가 1차 시기에 애플리케이션을 요청하면, 앱 시작 번들은 클라이언트 디바이스로 송신되는 반면 주문형 리소스를 포함하는 다른 자산 팩들은 서버에 남아 있을 수 있다. 바람직하게는, 앱 시작 번들은 애플리케이션을 초기에 실행하는 데 요구되는 소프트웨어 코드 및 애플리케이션 리소스들만을 포함한다. 예를 들어, 도 1을 다시 참조하면, 비디오 게임 애플리케이션(100)의 앱 시작 번들(140)은 단지 파일들(142, 144, 146), 기본 리소스 팩(130), 및 레벨 1 팩(108)을 포함할 수 있으며, 이는 클라이언트 디바이스에서 게임을 시작하는 데 요구되는 모든 것들을 구성한다. 일 실시예에서, 애플리케이션의 개발자는, 그것들의 태그들에 기초하여, 앱 시작 번들에 포함되는 애플리케이션 리소스들을 선택할 수 있다(예컨대, "레벨 1" 태그가 붙은 모든 애플리케이션 리소스들이 위의 예에서 선택됨). 다른 주문형 리소스들(예컨대, 레벨 2 및 레벨 3 팩의 리소스들)은 앱 시작 번들(140)에서 제외되기 때문에, 애플리케이션은 전체 애플리케이션이 단일 번들에 다운로드되는 경우보다 초기에 클라이언트 디바이스 상의 공간을 훨씬 덜 차지할 수 있다.

게임(100)이 설치된 이후 사용자가 게임의 레벨 1을 진행함에 따라, 후속 레벨(들)을 실행하는 데 요구되는 자산 팩들이 요청되어 클라이언트 디바이스에 설치될 수 있다. 자산 팩들을 요청하고 설치하기 위한 다양한 조건들은, 예를 들어, 자산 팩들이 언제 및/또는 어떻게 활용되는지에 기초하여 설정될 수 있다. 또한, 레벨 1 자산 팩은 사용자가 게임의 레벨 1을 완수한 이후에 더 이상 필요없을 수 있고, 따라서 불가피한 경우 클라이언트 디바이스에서 제거될 수 있다. 클라이언트 디바이스 상의 자산 팩들(즉, 주문형 리소스들)을 동적으로 업데이트하는 예시적인 방법이 도 3 및 도 4를 참조하여 다음 단락들에 기재된다.

도 3은 개시내용의 실시예에 따른, 디바이스 상의 하나 이상의 애플리케이션의 애플리케이션 리소스를 관리하는 클라이언트 디바이스의 예시적인 모듈들 및 그것들의 상호작용을 예시한다. 특히, 클라이언트 디바이스(300)는 디바이스의 운영 체제(OS)의 일부인 주문형 리소스 데몬(on demand resources daemon: ODR)(302)을 포함할 수 있다. ODR(302)은 클라이언트 디바이스 상의 다수의 애플리케이션들에 걸쳐 모든 양태의 애플리케이션 리소스 관리를 처리하도록 프로그램될 수 있다. 특히, ODR(302)은 애플리케이션의 사용 및 디바이스 상의 이용가능한 저장 공간을 모니터하고 필요에 따라 주문형 리소스들을 페치 및 제거할 수 있다. 데몬이기 때문에, ODR(302)은 통상적으로 상호작용 사용자에 의해 직접 제어되지 않으면서 백그라운드에서 태스크를 수행할 수 있다.

도 3에 예시된 바와 같이, ODR(302)은 클라이언트 디바이스 상의 애플리케이션(304)과 통신할 수 있다. 도 3에는 오직 하나의 애플리케이션(304)이 예시되지만, ODR(302)은 다수의 애플리케이션들과 상호작용하고 각각의 애플리케이션에 대하여 동일한 기능을 수행할 수 있음을 이해해야 한다. 이 실시예에서, 애플리케이션(304)은 리소스들 중 일부만이 초기 다운로드의 일부분이고 클라이언트 디바이스(300) 상에 상주하도록 주문형 리소스들로 구축된 애플리케이션일 수 있다. 주문형 리소스의 나머지는 원격 서버(306) 상에 저장된 하나 이상의 자산 팩에 보관될 수 있다.

클라이언트 디바이스(300)의 저장 매체(308)의 영역은 디바이스(300) 상의 다양한 애플리케이션들(304)의 애플리케이션 리소스들에 대한 저장 영역으로서 지정될 수 있다. 지정된 저장 영역(308)은 그 안의 애플리케이션 리소스들의 집합체를 업데이트하기 위해 ODR(302)에 액세스가능할 수 있다. 선택적으로, 클라이언트 디바이스(300)는 클라이언트 디바이스(300) 상의 이용가능한 저장 공간(애플리케이션 리소스들에 대한 지정된 저장 영역(308)을 포함)을 모니터하고, 저장 공간의 부족이 검출되면 ODR(302)과 통신하도록 구성될 수 있는 저장 공간 모니터링 모듈(또는 캐시 삭제 모듈)(310)을 또한 포함할 수 있다.

클라이언트 디바이스(300)는 명료함을 위해 도 3에 도시되지 않은 기타 하드웨어 모듈 및 소프트웨어 모듈을 포함할 수 있음을 이해해야 한다. 예를 들어, 클라이언트 디바이스(300)는 디바이스(300) 상에서 애플리케이션 및 기타 프로그램들을 실행하기 위한 프로세서를 포함할 수 있다. 그것은 또한 추가적인 저장 공간, 하나 이상의 네트워크를 통해 다른 디바이스(예컨대, 서버(306))와 통신하기 위한 네트워크 모듈, 디스플레이, 터치 스크린, 및 기타 센서와 같은 입출력(I/O) 디바이스를 포함할 수 있다.

도 4는 개시내용의 실시예에 따른, 클라이언트 디바이스 상에서 주문형 리소스를 이용하여 애플리케이션을 설정 및 실행하는 예시적인 단계들을 예시한다. 사용자가 앱 스토어에서 애플리케이션(304)의 다운로드를 요청하면, 애플리케이션(304)의 앱 시작 번들은 원격 서버(306)에서 클라이언트 디바이스(300)로 송신될 수 있다(단계(401)). 도 1의 비디오 게임을 예로 들면, 앱 시작 번들은 소프트웨어 코드, 기본 리소스 팩, 및 선택적으로 "레벨 1" 자산 팩만을 포함할 수 있다. 선택적으로, 사용자가 애플리케이션을 다운로드하도록 인가받았는지 검증하기 위한 인증 단계가 포함될 수 있다. 예를 들어, 애플리케이션이 회사에서 소정 개인에게는 액세스가 제한된 엔터프라이즈 ODR 애플리케이션인 경우, 이 인증 단계가 포함될 수 있다. 애플리케이션은 디바이스 상에 설치될 수 있고 앱 시작 번들의 리소스들(초기 다운로드의 일부분인 임의의 자산 팩들을 포함)은 클라이언트 디바이스(300)의 로컬 저장 영역(308)에 저장될 수 있다(단계(402)). 애플리케이션이 성공적으로 설치되면, 사용자는 애플리케이션(게임)을 기동시키고 클라이언트 디바이스 상에서 국부적으로 이용가능한 리소스들을 이용하여 게임의 레벨 1의 플레이를 시작할 수 있다. 사용자가 다음 레벨로 이동하기 전에 하나의 레벨을 완수해야 하도록 게임이 설계되어 있다면, 레벨 2 내지 레벨 N에 필요한 애플리케이션 리소스들은 게임의 초기 스테이지 동안 서버(306) 상에 남아 있을 수 있다. 애플리케이션(304)은 게임에서 사용자의 진행 상황을 모니터할 수 있다(단계(403)). 예를 들어, 애플리케이션(304)은, 사용자가 곧 레벨 1을 완수할 것이라고 결정하면, 다음 레벨(예컨대, 레벨 2)이 다운로드되어 있어서 국부적으로 이용가능한지 결정할 수 있다. 그렇지 않은 경우, 다음 레벨에 대한 요청이 ODR(302)에 송신될 수 있다(단계(404)). 대안적으로, 리소스에 대한 요청은, 사용자가 레벨 1을 시작하자 마자 또는 임의의 기타 사전정의된 트리거 이벤트들이 검출되면(예컨대, 게임에서 사용자가 사전결정된 지점으로 진행한 이후) 송신될 수 있다.

ODR(302)이 애플리케이션(304)으로부터 요청을 수신하면, 먼저 애플리케이션의 자산 팩 목록이 이용가능한지 결정할 수 있다(단계(405)). 자산 팩 목록은 자산 팩들이 요청될 수 있는 순서 및 네트워크 상의 자산 팩의 위치에 관한 정보를 포함할 수 있다. 자산 팩 목록이 이용가능하지 않은 경우, ODR(302)은 서버에 그것을 요청할 수 있다(단계(406)). 몇몇 애플리케이션들(예컨대, 결제 앱)은 서버가, 자산 팩 목록을 요청하는 개체(예컨대, 사용자 또는 클라이언트 디바이스)가 애플리케이션의 인가받은 소유자이고, 따라서 애플리케이션에 대한 자산 팩 목록을 수신할 자격이 됨을 검증하도록 요구할 수 있다(단계(407)). 이 검증은 사용자의 구매 이력에서 애플리케이션을 검색하는 것과 같은 임의의 적합한 방법들을 이용하여 수행될 수 있다. 이 검증 단계는 일부 애플리케이션들(예컨대, 무료 애플리케이션)에 대하여 생략되거나 아니면 항상 긍정적인 응답을 생성할 수 있다.

이어서 서버는 클라이언트(300) 상의 ODR(302)에 자산 팩 목록을 송신할 수 있다(단계(408)). ODR은 자산 팩 목록을 이용하여 다음에 다운로드할 자산 팩(들) 및 그것의 네트워크 상의 어드레스(예컨대, URL)를 식별할 수 있다(단계(409)). 이어서 자산 팩(들)에 대한 요청이 작성되어 그 어드레스에 송신될 수 있다(단계(410)). 일 실시예에서, 요청은, 요청받고 있는 주문형 리소스들(및 그것들의 대응하는 자산 팩들)을 식별하는 하나 이상의 태그(예컨대, 레벨 2)를 포함할 수 있다.

자산 팩들이 인가받은 개체(예컨대, 애플리케이션을 구매한 사용자)에 의해 요청받고 있음을 보장하기 위하여 자산 팩 목록에 통합될 수 있는 추가적인 보안 수단들이 있다. 일부 실시예들에서, 자산 팩 목록 내의 각각의 URL은 만료 기한(예컨대, 12 시간)을 가질 수 있다. 따라서 자산 팩 목록이 인가받지 않은 개체와 공유되는 경우에도, URL은 제한된 기간에만 유효할 것이다. 기간 종료시, 자산 팩 목록의 로컬 사본이 만료된 경우, 인가받은 개체도 서버에 새로운 자산 팩들을 요청하기 전에 자산 팩 목록을 갱신하도록 요구받을 수 있다.

추가적으로 또는 대안적으로, 자산 팩 목록은 ODR(302)의 자산 팩 요청을 인증하기 위하여 적어도 하나의 "시한 폭탄" URL을 포함할 수 있다. 이 "시한 폭탄"은 타임스탬프 및 서버에만 알려진 비밀 키로 URL의 일부분들을 해시함으로써 생성되는 보안 키일 수 있다. 자산 팩에 대한 요청이 서버로 송신될 때, 요청은 타임스탬프가 통합된 URL을 포함할 수 있다. 서버가 요청을 수신하면, URL 및 요청 내의 타임스탬프가 서버의 비밀 키와 해시하여 올바른 보안 키를 생성할 수 있는지 결정할 수 있다. 올바른 보안 키가 생성되는 경우, 서버는 요청받은 자산 팩(들)을 배포할 수 있다. 그렇지 않으면, 요청은 거절될 수 있다.

도 4를 다시 참조하면, 자산 팩에 대한 요청이 확인된 이후에, 서버는 자산 팩을 클라이언트 디바이스(300) 상의 요청한 ODR(302)에 선적할 수 있다(단계(411)). 자산 팩은 클라이언트 디바이스의 지정된 저장 공간(308)에 저장될 수 있다(단계(412)). 그 동안 또는 그 이후에, 애플리케이션(304)은 ODR(302)에 의해 새로운 자산 팩의 도착에 관해 통지받고 그것에 액세스할 수 있는 권한을 허가받을 수 있다(단계(413)). 이어서 프로그램이 레벨 1에 대한 애플리케이션 리소스들을 호출할 때(예컨대, 사용자가 레벨 1을 완수하고 레벨 2를 시작할 때), 애플리케이션은 자산 팩(예컨대, 레벨 2 팩)을 로딩할 수 있다(단계(414)).

단계들(403 내지 414)은 애플리케이션이 실행되고 애플리케이션의 상태(예컨대, 사용자 진행상황)에 따라 새로운 자산 팩들이 필요해지는 한 반복될 수 있다. 이 단계들 중 몇몇(예컨대, 단계들(406 내지 408))은 클라이언트 디바이스 상의 자산 팩 목록이 만료되지 않은 경우 생략될 수 있다. 바람직한 실시예에서, ODR(302)은, 예를 들어, 애플리케이션의 실행 상태, 사용 패턴 데이터, 및/또는 네트워크 강도에 기초하여 주문형 리소스들에 대한 수요를 예상하고, 이것들을 실제로 애플리케이션(304)이 요구하기 전에 자동으로 이 리소스들을 포함하는 자산 팩들을 프리페치할 수 있다. 클라이언트 디바이스의 플랫폼(예컨대, 디바이스의 유형)에 따라, ODR(302)은 더 적극적으로 또는 덜 적극적으로 자산 팩들을 프리페치하도록 프로그램될 수 있다. 디바이스가 상대적으로 큰 저장 공간 및/또는 열악한 네트워크 액세스를 가진 경우, ODR은 더 적극적으로 자산 팩들을 로딩하여 디바이스가 네트워크 접속을 놓치고 추가적인 리소스들을 다운로드할 수 없을 때 애플리케이션이 장애를 겪지 않도록 할 수 있다. 대조적으로, 저장 영역이 상대적으로 작지만 네트워크 접속이 빠르고 안정적인 디바이스의 ODR은 주문형 리소스들을 프리페치하는 데 덜 적극적일 수 있다. 대신, 그와 같은 디바이스의 ODR은 리소스가 요구됨에 따라 더 자주 요청을 할 것이다.

주문형 리소스를 다운로드하는 이러한 전체 프로세스는 어떠한 사용자 입력도 요구하지 않으면서 백그라운드에서 수행될 수 있다. 주문형 리소스는, 그것들이 초기 설치 때부터 이미 애플리케이션의 일부였던 것처럼 애플리케이션에 그대로 이용될 수 있다. 실제로, 사용자는 애플리케이션의 일부분들이 런타임 중에 서버로부터 동적으로 다운로드되고 있다는 것을 알지 못할 것이다.

위에서 기재한 바와 같이, 애플리케이션과 연관된 애플리케이션 리소스들을 자산 팩으로 그룹화함으로써, 애플리케이션이 정상적으로 실행되는 시간 내내 모든 애플리케이션 리소스들이 클라이언트 디바이스 상에 상주해야 하는 것은 아니다. 결과적으로, 상대적으로 큰 애플리케이션도 많은 저장 공간을 차지하지 않으면서 클라이언트 디바이스 상에 설치될 수 있다. 이는 결과적으로 다른 애플리케이션 및 데이터를 위한 저장 공간을 해방시킬 수 있다.

애플리케이션이 주문형 리소스들을 요청하면 애플리케이션과 연관된 주문형 리소스들은 개별적으로 서버로부터 획득될 수 있을 뿐만 아니라, 애플리케이션이 더 이상 주문형 리소스들을 곧 또는 장기적으로 향후 필요로 하지 않으면 동일한 주문형 리소스는 애플리케이션의 나머지 부분에 영향을 주지 않으면서 제거될 수 있다. 일부 실시예들에서, 주문형 리소스는, 그것들을 더 이상 애플리케이션이 필요로 하지 않으면 곧 제거될 수 있다. 다른 실시예들에서, 애플리케이션이 더 이상 그것들을 활용하지 않아도 주문형 리소스가 디바이스 상에 보존될 수 있다. 그것들은 오직 디바이스 상의 저장 공간의 부족에 응답하여 제거될 수 있다. 또 일부 다른 실시예들에서, 주문형 리소스들은, 그것들이 애플리케이션에 아직 유용할 수 있는 경우에도 제거될 수 있다. 리소스를 제거하는 기준 및 우선순위는 또한 애플리케이션을 구축할 때 개발자에 의해 설정될 수 있다.

도 5는 개시내용의 실시예에 따른, 클라이언트 디바이스로부터 애플리케이션 리소스를 제거하는 예시적인 단계들을 예시한다. 도 3의 저장 공간 모니터링 모듈(캐시 삭제 모듈)(310)은 클라이언트 디바이스 상의 공간 사용을 모니터할 수 있다(단계(501)). 예를 들어, 사용자가 새로운 애플리케이션 또는 콘텐츠를 디바이스(300)에 다운로드하려고 한 결과, 공간의 부족을 검출하게 되면, 새로운 애플리케이션/콘텐츠를 위하여 일부 공간을 해방하기 위한 요청을 ODR(302)에 송신할 수 있다(단계(502)). 일부 실시예들에서, ODR(302)은 이용가능한 공간의 부족에 대하여 통지되지 않아도 스스로 공간 청소 프로세스를 개시할 수 있다. 이에 응답하여, ODR(302)은 지정된 저장 공간(308)에 저장된 자산 팩들을 조사하고 어떤 자산 팩이, 대응하는 애플리케이션에 의해 활용되지 않을 가능성이 있으며, 그럼으로써 디바이스(300)로부터 제거될 수 있는 리소스들을 포함하는지 결정할 수 있다(단계(503)). 다양한 기준은 어떤 리소스들이 제거가능한지 그리고 그것들이 제거될 수 있는 순서에 관해 설정될 수 있으며, 이는 아래 단락에 상세하게 기재된 바와 같다. 바람직하게는, ODR(302)은 적어도 리소스가 적어도 하나의 애플리케이션에 의해 계속 요청받고 있는 한 그 리소스 또는 그 리소스를 포함하는 자산 팩을 저장 영역(308)으로부터 제거하기 위하여 시도하지 않도록 프로그램된다. 어떤 자산 팩(또는 애플리케이션)이 제거될지에 관한 선택이 이루어진 이후에, ODR(302)은 저장 영역(308)으로부터 그것을 삭제할 수 있다(단계(504)).

다양한 실시예들에서, ODR(302)은 제거할 주문형 리소스들을 하나 이상의 상이한 기준에 기초하여 선택하도록 프로그램될 수 있다. 일 실시예에서, ODR(302)은 더 이상 필요하지 않은(예컨대, 어떠한 애플리케이션에 의해서도 요청되지 않음) 임의의 주문형 리소스 또는 모든 주문형 리소스들을 간단하게 제거할 수 있다. 자산 팩 및 그것의 애플리케이션 리소스들이 더 이상 애플리케이션에 의해 요청되지 않고 가까운 장래에 다시 필요할 가능성이 없으면, 자산 팩/리소스는 제거가능한 것으로 표시되고/되거나 제거 후보군들의 리스트의 상단으로 배치될 수 있다. 자산 팩이 여전히 애플리케이션에 의해 호출되고/되거나 적어도 일정 정도 계속 활용될 것으로 예상되는 경우, 자산 팩은 보존되는 것으로 표시되고/되거나 제거 리스트의 하단에 랭크될 수 있다. 예를 들어, 사용자가 게임의 레벨 1을 완수했지만, 여전히 레벨 2에서 활동하고 있는 경우, 자산 팩 "레벨 2"는 "보존"으로 표시되고/되거나 제거 리스트 상의 자산 팩 "레벨 1"보다 하단에 랭크될 수 있다. 제거 리스트는 클라이언트 디바이스 상에 설치된 하나 이상의 애플리케이션과 연관된 자산 팩들/리소스들을 포함할 수 있다. 자산 팩들/리소스들의 랭킹은, 적어도 부분적으로, 애플리케이션의 실행 상태에 기초하여 동적으로 변경될 수 있다.

추가적으로 또는 대안적으로, ODR(302)은 애플리케이션 개발자에 의해 설정된 선호도에 기초하여 선택할 수 있다. 이 선호도는 각각의 자산 팩과 연관된 메타데이터의 일부분으로서 자산 팩 목록 내에 저장될 수 있다. 예를 들어, 개발자는 하나의 자산 팩과 연관된 "삭제 금지" 플래그를 1로 설정하여 애플리케이션이 디바이스로부터 삭제되지 않는 한 이 특정 자산 팩은 항상 클라이언트 디바이스 상에 남아 있어야함을 나타낼 수 있다. 다른 자산 팩에 대하여 동일한 플래그가 0으로 설정된 경우, 자산 팩은 제거 후보가 될 수 있다. 다른 예로서, 개발자는 애플리케이션 내의 각각의 자산 팩(또는 주문형 리소스)에 대하여 우선순위 번호를 설정할 수 있다. 우선순위 번호는 애플리케이션의 다양한 자산 팩들(또는 리소스들) 가운데서 선호하는 제거 순서를 나타낼 수 있다. ODR(302)이 디바이스 상에서 빈 공간을 찾을 때, 예를 들어, 가장 낮은 우선순위 번호를 이용하여 자산 팩들을 검색할 수 있다.

추가적으로 또는 대안적으로, 제거(및/또는 다운로드) 순서에 경험이 반영될 수 있다. 특히, 다수의 클라이언트 디바이스들에 걸친 애플리케이션의 상이한 사용 패턴들이 수집될 수 있다. 이러한 사용 패턴들에 기초하여, 애플리케이션을 실행하는 동안 자산 팩들이 상이한 스테이지에서 활용될 가능성이 있는 순서에 대해 예측이 이루어질 수 있다. 사용 패턴들은 또한, 예를 들어, 자산 팩들의 각각의 전체 활용률을 나타낼 수 있다. 그것은 또한 얼마나 자주 및/또는 언제 애플리케이션이 특정 사용자에 의해 사용될 가능성이 있는지 나타낼 수 있다. 예를 들어, 애플리케이션이 통상적으로 주말에만 사용되는 경우, 저장 공간이 여유가 없다면 각 주말 이후에 제거 후보가 될 가능성이 있을 수 있다. 주말동안 사용될 가능성이 낮은 다른 애플리케이션/리소스를 제거함으로써 주말 전에 재설치될 수 있다.

다른 예로서, 사용자가 동일한 애플리케이션을 다수의 클라이언트 디바이스들에 다운로드한 경우, 제1 디바이스 상의 애플리케이션에서의 사용자의 진행상황이 추적되고 원격 서버에 저장되어, 사용자가 제2 디바이스로 옮겨가면, 사용자가 제2 디바이스 상에서 애플리케이션을 사용하기 시작하기 전에 사용자의 세션을 재개하는 데 필요한 애플리케이션 리소스들이 제2 디바이스 상에 프리페치될 수 있다.

또 다른 예로서, 클라이언트 디바이스 상의 애플리케이션이 다수의 사용자들에 의해 공유되는 경우, 애플리케이션의 각각의 사용자의 사용은, 예를 들어, 그들의 디바이스/애플리케이션 로그인에 기초하여 클라이언트 측에서 별도로 추적될 수 있다. 제1 사용자가 클라이언트 디바이스/애플리케이션을 로그온하면, ODR(302)은, 사용자의 이전 앱 사용 패턴에 기초하여, 그가 사용할 가능성이 있는 애플리케이션/자산 팩들이 디바이스 상에서 이용가능한지 결정할 수 있다. 그렇지 않은 경우, ODR은 사용자가 디바이스에 로그온하자마자 서버에 이 애플리케이션/자산 팩들을 요청할 수 있다. 일부 실시예들에서, 충분한 저장 공간이 디바이스 상에서 이용가능하지 않은 경우, ODR은 다른 사용자들에 의해 다운로드되었던 다른 애플리케이션/자산 팩들을 제거할 수 있다. 제2 사용자가 디바이스에 로그온하면, 그의 애플리케이션/자산 팩들이 자동으로 디바이스에 로딩될 수 있고, 제1 사용자와 연관된 애플리케이션/자산 팩들은, 불가피한 경우, 제거되어 저장 공간을 해방시킬 수 있다. 다수의 사용자들이 동일한 애플리케이션 또는 애플리케이션의 자산 팩(들)을 공유하는 경우, 애플리케이션 또는 자산 팩(들)은 어떤 사용자가 디바이스에 로그온하는지에 상관없이 디바이스 상에 남아 있을 수 있다.

클라이언트 디바이스의 플랫폼(예컨대, 디바이스의 유형)에 따라, ODR(302)은 또한 더 적극적으로 또는 덜 적극적으로 자산 팩들을 제거하도록 프로그램될 수 있다. 디바이스가 상대적으로 큰 저장 공간 및/또는 열악한 네트워크 액세스를 가진 경우, ODR은 자산 팩들을 제거하는 데 덜 적극적일 수 있다. 대조적으로, 저장 영역이 상대적으로 작지만 네트워크 접속이 빠르고 안정적인 디바이스의 ODR은 주문형 리소스들을 제거하는 데 더 적극적일 수 있다.

일 실시예에서, 자산 팩들은 단지 애플리케이션뿐만 아니라, 특정 버전의 애플리케이션과도 연관될 수 있다. 통상적으로, 애플리케이션에 변경이 일어나면 새로운 버전의 애플리케이션이 출시될 수 있다. 본 개시내용의 실시예들에서 개시된 애플리케이션의 다양한 리소스들이 다수의 자산 팩들로 그룹화될 수 있기 때문에, 새로운 버전의 애플리케이션이 출시되면 자산 팩들 중 적어도 일부에는 어떠한 변경도 없을 수 있다. 새로운 버전의 변경이 상대적으로 중요하지 않은 경우, 대부분의 자산 팩들은 갱신될 필요가 없을 수 있다. 오직 업데이트된 자산 팩들만이 이전 버전을 대체하기 위하여 다시 다운로드될 필요가 있다. 일 실시예에서, 각각의 자산 팩의 콘텐츠는 해시되어 콘텐츠 해시를 생성할 수 있고, 이는 새로운 버전의 자산 팩이 배포될 때 임의의 콘텐츠가 변경되었는지 결정하는 데 사용될 수 있다. 새로운 버전에 대한 콘텐츠 해시가 현재 버전의 콘텐츠 해시와 동일한 경우, 특정 자산 팩을 다시 다운로드할 필요가 없다. 새로운 버전에 대한 콘텐츠 해시가 현재 버전의 콘텐츠 해시와 매치되지 않는 경우, 새로운 버전의 자산 팩이 다운로드되어 현재 버전을 대체할 수 있다. 바람직하게는, 자산 팩과 연관된 별로 관련없는 정보(예컨대, 타임스탬프, 코드 서명, 및 기타 메타데이터)의 일부가 변경되는 경우에도, 콘텐츠 해시는 동일할 수 있다. 콘텐츠 해시는 자산 팩의 실제 콘텐츠(즉, 리소스)가 변경된 경우에만 변경되어야 한다.

도 6은 개시내용의 실시예에 따른, 애플리케이션을 주문형 리소스를 이용하여 새로운 버전으로 업데이트하는 예시적인 단계들을 예시한다. 우선, 클라이언트 디바이스가 서버로부터 1차 시기에 자산 팩(또는 앱 시작 번들)을 수신하면(단계(601)), 자산 팩(또는 앱 번들)의 실제 콘텐츠(즉, 리소스)에 기초하여 콘텐츠 해시를 계산하고 저장할 수 있다(단계(602)). 서버가 애플리케이션의 새로운 업데이트를 수신하면, 애플리케이션 내의 각각의 자산 팩/번들에 대한 콘텐츠 해시를 재계산할 수 있다(단계(603)). 재계산된 콘텐츠 해시는 자산 팩 목록 내에 포함될 수 있다(단계(604)). 클라이언트 디바이스가 최근 자산 팩 목록을 요청하면, 그것은 또한 모든 자산 팩들에 대한 재계산된 콘텐츠 해시들을 획득할 수 있다(단계(605)). 이어서 클라이언트 디바이스는 재계산된 콘텐츠 해시들을 국부적으로 저장된 각각의 콘텐츠 해시들과 비교하여 변경된 자산 팩들을 식별할 수 있다(단계(606)). 이어서 클라이언트 디바이스는 애플리케이션 업데이트를 위하여 모든 자산 팩들을 다운로드하는 대신에 이 식별된 자산 팩들만 요청할 수 있다(단계(607)). 콘텐츠 해시를 이용하여 자산 팩들에 대한 업데이트를 검증하기 위하여, 각각의 자산 팩은 버전 업데이트에 걸쳐 안정적으로 유지될 수 있는 식별자를 포함할 수 있다. 일 실시예에서, 각각의 자산 팩과 연관된 태그(또는 태그들의 조합)는 그 자산 팩의 식별자로서 사용될 수 있다.

개시내용의 다른 양태에서, 애플리케이션 프로그램 인터페이스(API)(또는 API의 세트)가 주문형 리소스들로 애플리케이션을 구축하는 애플리케이션의 개발자들에게 제공될 수 있다.

API는 프로그램 코드 컴포넌트 또는 하드웨어 컴포넌트(이하에서 "API 구현 컴포넌트"라고 함)에 의하여 구현되는 인터페이스로서, API 구현 컴포넌트는 상이한 프로그램 코드 컴포넌트 또는 하드웨어 컴포넌트(이하에서, "API 호출 컴포넌트"라고 함)가 API 구현 컴포넌트에 의해 제공되는 하나 이상의 기능, 방법, 절차, 데이터 구조, 클래스 및/또는 다른 서비스에 액세스 하여 이를 사용하게 한다. API는 API 호출 컴포넌트와 API 구현 컴포넌트 사이에서 전달되는 하나 이상의 파라미터들을 정의할 수 있다.

API는 API 호출 컴포넌트의 개발자(제3자의 개발자일 수 있음)가 API 구현 컴포넌트에 의해 제공되는 규정된 특징부에 영향을 주게 한다. 하나의 API 호출 컴포넌트가 있을 수 있거나, 하나 초과의 그러한 컴포넌트가 있을 수 있다. API는 애플리케이션으로부터의 서비스 요청을 지원하기 위하여 컴퓨터 시스템 또는 프로그램 라이브러리가 제공하는 소스 코드 인터페이스일 수 있다. 운영 체제(OS)는 다수의 API들을 가져서 OS 상에서 실행되는 애플리케이션이 그 API들 중 하나 이상을 호출하게 할 수 있으며, (프로그램 라이브러리와 같은) 서비스는 다수의 API들을 가져서 그 서비스를 사용하는 애플리케이션이 그 API들 중 하나 이상을 호출하게 할 수 있다. API는 애플리케이션이 구축될 때 인터프리팅(interpreting)되거나 컴파일링(compiling)될 수 있는 프로그래밍 언어에 의해 규정될 수 있다.

일부 실시예들에서, API 구현 컴포넌트는 하나 초과의 API를 제공할 수 있고, API는 각각 API 구현 컴포넌트에 의해 구현되는 기능의 상이한 측면들에 액세스하는 상이한 측면들의 상이한 뷰 또는 상이한 측면들을 갖는 상이한 뷰를 제공한다. 예를 들어, API 구현 컴포넌트 중 하나의 API는 제1 기능 세트를 제공할 수 있고 제3자의 개발자에게 노출될 수 있으며, API 구현 컴포넌트 중 다른 API는 숨겨질(노출되지 않을) 수 있고 제1 기능 세트의 하위세트(subset)를 제공하고 또한 제1 기능 세트에는 없는 테스팅 및 디버깅 기능과 같은 다른 기능 세트를 제공할 수 있다. 다른 실시예들에서, API 구현 컴포넌트 자체는 기본 API를 통해 하나 이상의 다른 컴포넌트를 호출할 수 있고, 따라서 API 호출 컴포넌트와 API 구현 컴포넌트 둘 모두가 될 수 있다.

API는 API 호출 컴포넌트들이 API 구현 컴포넌트의 규정된 특징부들에 액세스하여 이를 사용할 때 API 호출 컴포넌트가 사용하는 언어와 파라미터를 정의한다. 예를 들면, API 호출 컴포넌트는 API에 의해 노출된 하나 이상의 API 호출들 또는 (예를 들면, 기능 또는 메소드 호출들에 의하여 구현된) 인보케이션(invocation)들을 통해 API 구현 컴포넌트의 특정 특징부들에 액세스하고, API 호출들 또는 인보케이션들을 통해 파라미터들을 사용하여 데이터 및 제어 정보를 전달한다. API 구현 컴포넌트는 API 호출 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수 있다. API는 API 호출의 신택스(syntax)와 결과(예컨대, API 호출을 어떻게 작동시키는지 그리고 API 호출이 무엇을 하는지)를 정의하지만, API는 API 호출이 API 호출에 의하여 규정된 기능을 어떻게 성취하는지 드러내지 않을 수 있다. 호출(API 호출 컴포넌트)과 API 구현 컴포넌트 사이에서 하나 이상의 애플리케이션 프로그래밍 인터페이스를 통하여 다양한 API 호출들이 전달된다. API 호출들의 전달은 함수 호출 또는 메시지에 대한 발행, 개시, 작동, 호출, 수신, 반환 또는 응답을 포함하는데, 다시 말하면, 전달은 API 호출 컴포넌트 또는 API 구현 컴포넌트 중 어느 하나에 의한 작용들을 설명할 수 있다. API의 함수 호출들 또는 다른 인보케이션들은 파라미터 리스트 또는 다른 구조를 통하여 하나 이상의 파라미터들을 주고 받을 수 있다. 파라미터는 상수, 키(key), 데이터 구조, 객체, 객체 클래스, 변수, 데이터 유형, 포인터, 배열, 리스트 또는 함수 또는 메서드에 대한 포인터, 또는 API를 통해 전달될 데이터 또는 다른 항목을 참조하기 위한 다른 방법일 수 있다.

또한, 데이터 유형 또는 클래스가 API에 의하여 제공되고 API 구현 컴포넌트에 의하여 구현될 수 있다. 따라서, API 호출 컴포넌트는 API에서 제공되는 정의들을 사용함으로써 그러한 유형들 또는 클래스들의 변수들을 선언하거나, 이들에 대한 포인터들을 사용하거나, 이들의 상수 값을 사용 또는 인스턴스화할(instantiate) 수 있다.

일반적으로, API를 사용하여 API 구현 컴포넌트에 의하여 제공되는 서비스 또는 데이터에 액세스하거나 API 구현 컴포넌트에 의하여 제공되는 동작 또는 연산의 수행을 개시할 수 있다. 예로서, API 구현 컴포넌트 및 API 호출 컴포넌트는 각각 운영 체제, 라이브러리, 디바이스 구동기, API, 애플리케이션 프로그램, 또는 다른 모듈 중에서 임의의 것일 수 있다(API 구현 컴포넌트 및 API 호출 컴포넌트가 서로 동일하거나 상이한 유형의 모듈일 수 있음이 이해되어야 한다). API 구현 컴포넌트들은 일부 경우에 적어도 부분적으로 펌웨어, 마이크로코드 또는 다른 하드웨어 로직으로 실시될 수 있다. 일부 실시예들에서, API는 클라이언트 프로그램이 소프트웨어 개발 도구(Software Development Kit; SDK) 라이브러리에 의해 제공된 서비스들을 사용하도록 허용할 수 있다. 다른 실시예들에서, 애플리케이션 또는 다른 클라이언트 프로그램은 애플리케이션 프레임워크에 의해 제공되는 API를 사용할 수 있다. 이 실시예들에서, 애플리케이션 또는 클라이언트 프로그램은 호출들을 SDK에 의해 제공되고 API에 의해 제공되는 함수들 또는 메서드들에 통합시킬 수 있거나 SDK에서 정의되고 API에 의해 제공되는 데이터 유형들 또는 객체들을 사용할 수 있다. 애플리케이션 프레임워크는 이 실시예들에서, 프레임워크에 의해 정의된 다양한 이벤트들에 응답하는 프로그램에 대한 메인 이벤트 루프(main event loop)를 제공할 수 있다. API는 애플리케이션이 애플리케이션 프레임워크를 사용하여 이벤트들 및 이벤트들에 대한 응답들을 명시하게 할 수 있다. 일부 구현들에서, API 호출은 입력 능력 및 상태, 출력 능력 및 상태, 처리 능력, 전원 상태, 저장 용량 및 상태, 통신 능력 등과 같은 측면들에 관계되는 것들을 비롯한 하드웨어 디바이스의 능력 또는 상태를 애플리케이션에 보고할 수 있고, API는 펌웨어, 마이크로코드, 또는 하드웨어 컴포넌트 상에서 부분적으로 실행되는 다른 저레벨 로직에 의하여 부분적으로 구현될 수 있다.

API 호출 컴포넌트는 로컬 컴포넌트(즉, API 구현 컴포넌트와 동일한 데이터 프로세싱 시스템 상의) 또는 네트워크에 걸쳐 API를 통해 API 구현 컴포넌트와 통신하는 원격 컴포넌트(즉, API 구현 컴포넌트와 상이한 데이터 프로세싱 시스템 상의)일 수 있다. API 구현 컴포넌트가 또한 API 호출 컴포넌트로서의 역할을 할 수도 있고(즉, 그것은 상이한 API 구현 컴포넌트에 의해 노출된 API에 API 호출을 행할 수 있다), 상이한 API 호출 컴포넌트에 노출되는 API를 구현함으로써 API 호출 컴포넌트가 또한 API 구현 컴포넌트로서의 역할을 할 수 있음이 이해되어야 한다.

API는 상이한 프로그래밍 언어들로 기록된 다수의 API 호출 컴포넌트들이 API 구현 컴포넌트와 통신하도록 허용할 수 있다(따라서, API는 호출들을 해석하기 위한 특징부들을 포함할 수 있고 API 구현 컴포넌트와 API 호출 컴포넌트 사이에 리턴한다); 그러나, API는 특정 프로그래밍 언어의 관점에서 구현될 수 있다. 일 실시예에서, API 호출 컴포넌트는 OS 공급자로부터의 API 세트, 플러그인 공급자로부터의 다른 API 세트, 다른 API 세트의 다른 공급자(예컨대, 소프트웨어 라이브러리의 공급자) 또는 생성자로부터의 다른 API 세트와 같은, 상이한 공급자들로부터의 API들을 호출할 수 있다.

도 7은 개시내용의 일부 실시예들에 사용될 수 있는 예시적인 API 아키텍처를 예시하는 블록도이다. 도 7에 도시된 바와 같이, API 아키텍처(700)는 API(720)를 구현하는 API 구현 컴포넌트(710)(예컨대, 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 소프트웨어 또는 다른 모듈)를 포함한다. API(720)는 하나 이상의 함수, 메소드, 클래스, 객체, 프로토콜, 데이터 구조, 포맷, 및/또는 API 호출 컴포넌트(730)에 의해 사용될 수 있는 API 구현 컴포넌트의 다른 특징부들을 규정한다. API(720)는 API 구현 컴포넌트 내의 함수가 어떻게 API 호출 컴포넌트로부터 파라미터들을 받는지, 그리고 이 함수가 어떻게 API 호출 컴포넌트로 결과를 반환하는지를 규정하는 적어도 하나의 호출 규약(calling convention)을 규정할 수 있다. API 호출 컴포넌트(730)(예컨대, 운영 체제, 라이브러리, 디바이스 구동기, API, 애플리케이션 프로그램, 소프트웨어 또는 다른 모듈)는 API(720)를 통해 API 호출을 하여 API(720)에 의해 규정되는 API 구현 컴포넌트(710)의 특징부들에 액세스하여 이를 사용한다. API 구현 컴포넌트(710)는 API 호출에 응답하여 API(720)를 통하여 API 호출 컴포넌트(730)로 값을 반환할 수 있다.

API 구현 컴포넌트(710)가 API(720)를 통해 특정되지 않고 API 호출 컴포넌트(730)가 이용가능하지 않은 추가 함수, 메소드, 클래스, 데이터 구조, 및/또는 다른 특징을 포함할 수 있음이 인식될 것이다. API 호출 컴포넌트(730)가 API 구현 컴포넌트(710)와 동일한 시스템 상에 있을 수 있거나, 원격으로 위치되어 네트워크를 통해 API(720)를 이용하여 API 구현 컴포넌트(710)에 액세스할 수 있다는 것을 이해해야 한다. 도 7은 API(720)와 상호작용하는 단일 API 호출 컴포넌트(730)를 도시하지만, API 호출 컴포넌트(730)와는 상이한 언어(또는 동일한 언어)로 작성될 수 있는 다른 API 호출 컴포넌트들이 API(720)를 사용할 수 있다는 것을 이해할 것이다.

API 구현 컴포넌트(710), API(720) 및 API 호출 컴포넌트(730)는 기계(예컨대, 컴퓨터 또는 다른 데이터 처리 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함하는 기계 판독가능한 매체에 저장될 수 있다. 예를 들어, 기계 판독가능한 매체는 자기 디스크, 광 디스크, RAM(random access memory), ROM(read only memory), 플래시 메모리 디바이스 등을 포함한다.

도 8("소프트웨어 스택")의 예시적인 실시예에서, 애플리케이션은 다수의 서비스 API를 이용하여 서비스 A 또는 B에 대한 호출을 할 수 있고, 다수의 OS API를 이용하여 운영 체제(OS)에 대한 호출을 할 수 있다. 서비스 A 및 서비스 B는 여러 OS API를 이용하여 OS로의 호출을 행할 수 있다.

서비스 2는 2개의 API를 갖는데, 그 중 하나(서비스 2 API 1)는 애플리케이션 1로부터 호출을 수신하고 그것에 값을 반환하며, 다른 것(서비스 2 API 2)은 애플리케이션 2로부터 호출을 수신하고 그것에 값을 반환함에 유의한다. 서비스 1(예를 들어, 소프트웨어 라이브러리일 수 있음)은 OS API 1로의 호출을 행하고 그로부터 반환 값을 수신하며, 서비스 2(예를 들어, 소프트웨어 라이브러리일 수 있음)는 OS API 1 및 OS API 2 둘 모두로의 호출을 행하고 그들로부터 반환 값을 수신한다. 애플리케이션 2는 OS API 2로의 호출을 행하고 그로부터 반환 값을 수신한다.

본 명세서에 개시된 API의 실시예는 다음의 예시적인 데이터 구조(예컨대, 객체 클래스), 파라미터, 및 루틴들을 포함할 수 있다. 이러한 예들은 오브젝트 C와 같은 임의의 적합한 프로그래밍 언어로 구현될 수 있음을 이해해야 한다.

이 예시적인 구현예에서, 리소스 요청 객체는 사실상 애플리케이션의 일부이지만 원격으로 저장되는 주문형 리소스들의 이용가능성을 관리할 수 있다. 애플리케이션은 연관된 리소스들이 필요할 때 그리고 그것들의 사용을 완료했을 때 시스템에 알리기 위한 요청을 사용할 수 있다. 이어서 리소스 요청은 디바이스 상에 아직 캐시저장되지 않은 임의의 리소스들을 다운로드하고, 리소스들이 사용할 준비가 되면 애플리케이션에 알릴 수 있다.

선택적 설정은 리소스들의 그룹들을 다운로드 및 제거하는 상대적인 우선순위에 대한 힌트를 제공할 수 있다. 그룹들은 애플리케이션에 필요한 것으로 표시될 수 있다. 플랫폼에 따라, 시스템은 저장장치에서 이 리소스들을 삭제하지 못할 수 있거나, 또는 애플리케이션이 기동될 때 그것들이 다운로드된다. 각각의 리소스 요청은 단 한번 리소스들에 액세스하는 데에 사용될 수 있다.

각각의 리소스 요청 객체는 관련 주문형 리소스들의 그룹을 관리할 수 있다. 태그들은 관련 리소스들의 각각의 세트에 대하여 생성되고, 애플리케이션이 구축되기 전의 주문형 리소스들에 배정될 수 있다. 리소스 요청은 그것이 관리하는 리소스들에 대한 태그들의 세트를 포함할 수 있다. 리소스 요청은 디바이스 상에 아직 없는 리소스들만 다운로드할 수 있다. 다운로드된 리소스는 앱 시작 번들에 있는 것들과 동일한 방식으로 액세스될 수 있다. 다운로드되지 않은 리소스에 액세스하는 것은 앱에 존재하지 않는 리소스에 액세스하는 것과 동일한 방식으로 작동할 수 있다.

시스템은 하나의 리소스 요청 객체가 리소스에 액세스할 수 있는 한 디바이스 상의 저장장치에서 리소스를 제거하려는 시도를 하지 않을 수 있다. 액세스는 액세스를 종료하라는 호출에 응답하거나 또는 리소스 요청 객체가 할당해제되면 종료할 수 있다.

주문형 리소스는 리소스 요청 객체들이 그것들에 액세스하지 않게 된 이후에 보존될 수 있다. 시스템이 더 많은 저장 공간을 요구함에 따라, 리소스는 제거될 수 있다. 태그가 붙은 리소스의 그룹은 상대적인 보존 우선순위를 가질 수 있다. 시스템은 더 낮은 우선순위 리소스들을 우선 제거하려고 시도할 수 있다.

태그가 붙은 리소스는 애플리케이션에 필요한 것으로 설정될 수 있다. 몇몇 플랫폼의 경우, 이것은 리소스가 더 이상 액세스되지 않을 때 리소스가 저장장치에서 삭제되는 것을 방지하고, 애플리케이션 기동에 걸쳐 그것들을 보존할 수 있다. 다른 플랫폼 상에서, 시스템은 애플리케이션을 기동시키기 전에 리소스들을 다운로드할 수 있다. 영구적으로 보존되는 것으로 표시된 리소스들은 애플리케이션에 의해 사용되는 전체 저장장치에 포함될 수 있다.

API는 다음의 예시적인 기능들을 제공할 수 있다. 예를 들어, 명시된 식별자로 태그를 붙인 원격 리소스들을 관리하기 위한 초기화된 리소스 요청은, 메인 번들에 저장된 하나 이상의 리소스들을 입력으로서 명시하는 태그(또는 태그들)의 이름을 이용하는 호출에 기초하여 생성될 수 있다. 각각의 태그의 값은 리소스들의 논리적 그룹에 배정된 식별자에 대응할 수 있다. 로딩된 리소스를 저장하는 데 사용되는 번들은 호출 내에 선택적 "번들" 파라미터를 포함함으로써 명시될 수 있다. 리소스 요청의 구성은 다운로드된 리소스들을 저장하는 데 사용되는 번들에 대한 레퍼런스를 사용함으로써 액세스될 수 있다. 번들은 메인 번들 또는 API 호출에 명시된 번들일 수 있다.

API는 또한 각각의 리소스 요청의 우선순위를 구성하는 방식을 제공할 수 있다. 이어서 시스템은 더 높은 값을 갖는 리소스 요청에 우선순위를 주도록 시도할 수 있다. 리소스 요청이 시작된 후에도, 리소스 요청의 우선순위는 임의의 시간에 변경될 수 있다.

API는 또한 리소스 요청 객체에 의해 관리되는 리소스들에 대한 액세스를 요청하는 방식을 제공할 수 있다. 리소스에 대한 액세스는 리소스 요청 객체에 의해 관리되는 리소스들이 이미 디바이스 상에 있는지에 따라 달라질 수 있다. 그것들이 있으면, 시스템은 리소스들에 대한 액세스를 시작할 수 있다. 리소스들이 디바이스 상에 없으면, 그것들은 서버에 요청될 수 있다. 시스템은 리소스들이 여전히 액세스될 수 있는 동안 그것들을 제거하지 못할 수 있다.

API는 추가적으로 리소스 요청 객체와 연관된 리소스들이 더 이상 액세스되지 않음을 시스템에 알리는 방식을 제공할 수 있다. 이 방법은 리소스 요청 객체가 할당해제될 때 호출될 수 있다. API는 또한 리소스 요청의 진행상황을 추적하는 방식을 제공할 수 있다.

또한, API는 또한 캐시저장 우선순위(예컨대, 리소스들을 제거하는 상대적 순서)를 구성하는 방식을 제공할 수 있다. 이 호출은 대응하는 태그(들)에 의해 명시되는 그룹들에 리소스들을 보존하는 상대적인 우선순위를 명시하는 번호일 수 있는 우선순위 파라미터를 요구할 수 있다. 시스템은 먼저 더 낮은 우선순위를 갖는 캐시저장된 리소스들을 제거하려고 시도할 수 있다. 또한, 부울 값은 시스템이 명시된 태그(들)과 연관된 리소스들을 제거할 수 있는지 명시하는 데 사용될 수 있다. 보존하도록 표시된 리소스들은 애플리케이션이 기동된 이후로 이용될 수 있다. 이는, 플랫폼에 따라, 시스템이 그것들을 제거하지 못하게 하거나 또는 애플리케이션이 기동될 때 그것들을 다운로드함으로써 수행될 수 있다. 리소스를 보존하기 위한 공통적인 이유들 중에 하나는 오프라인 사용일 수 있다.

또한, API는, 다운로드되는 리소스들에 대하여 이용가능한 디스크 공간의 양이 줄어들고 있음을 리소스 요청 시스템이 검출한 이후에 통지를 포스팅하는 방식을 제공할 수 있다. 통지를 수신한 이후에, 애플리케이션은, 예를 들어, 더 이상 필요없는 임의의 주문형 리소스들을 해제함으로써 디스크 공간을 해방시키도록 시도할 수 있다. 애플리케이션이 백그라운드에 있고 애플리케이션이 충분한 공간을 해방시키지 못하는 경우, 그것은 종료될 수 있다.

위에서 기재한, 주문형 리소스를 이용하여 애플리케이션을 구축, 배치, 실행, 및 업데이트하는 시스템 및 방법은 소프트웨어, 펌웨어, 하드웨어, 및/또는 이 셋의 임의의 조합으로 구현될 수 있다. 모듈들 중 하나 이상이 소프트웨어로 구현되는 실시예들에서, 그것들은 명령어 실행 시스템, 장치 또는 디바이스로부터 명령어들을 페치하여 명령어들을 실행할 수 있는 컴퓨터 기반 시스템, 프로세서 포함 시스템, 또는 다른 시스템과 같은, 명령어 실행 시스템, 장치, 또는 디바이스에 의해 또는 그와 관련하여 사용하기 위한 임의의 비일시적 컴퓨터 판독가능 저장 매체 내에서 저장 및/또는 전송될 수 있다. 본 명세서와 관련하여, "비일시적 컴퓨터 판독가능 저장 매체"는 명령어 실행 시스템, 장치, 또는 디바이스에 의해 또는 그와 관련하여 사용하기 위한 프로그램을 포함하거나 저장할 수 있는 임의의 매체일 수 있다. 비일시적 컴퓨터 판독가능 저장 매체는 전자, 자기, 광학, 전자기, 적외선, 또는 반도체 시스템, 장치 또는 디바이스, 휴대용 컴퓨터 디스켓(자기), 랜덤 액세스 메모리(RAM)(자기), 판독 전용 메모리(ROM)(자기), 소거가능 프로그래머블 판독 전용 메모리(EPROM)(자기), CD, CD-R, CD-RW, DVD, DVD-R, 또는 DVD-RW와 같은 휴대용 광학 디스크, 또는 콤팩트 플래시 카드, 보안 디지털 카드, USB 메모리 디바이스, 메모리 스틱과 같은 플래시 메모리 등을 포함할 수 있지만, 이에 제한되지 않는다. 비일시적 컴퓨터 판독가능 저장 매체는 컴퓨팅 디바이스의 저장 매체의 일부분일 수 있다.

위 실시예들은 비디오 게임을 참조하여 기재되었지만, 임의의 유형의 소프트웨어 애플리케이션은 개시된 시스템 및 방법을 이용하여 구현될 수 있음을 이해해야 한다.

실시예들이 첨부의 도면들을 참조하여 충분히 설명되었지만, 다양한 변경들 및 수정들이 본 기술 분야에서 통상의 지식을 가진 자에게 명백하게 될 것이라는 것에 주목하여야 한다. 그러한 변경들 및 수정들은 첨부된 청구항들에 의해 정의되는 바와 같은 다양한 실시예들의 범주 내에 포함되는 것으로서 이해되어야 한다.

Claims (30)

1. 디바이스 상에서 애플리케이션을 실행하는 컴퓨터 구현 방법으로서,
   네트워크 소스로부터 상기 애플리케이션의 앱 시작 번들(app start bundle)을 획득하는 단계;
   상기 앱 시작 번들을 이용하여 상기 애플리케이션을 설치하는 단계;
   1차 시기에 상기 애플리케이션의 제1 상태를 결정하는 단계;
   상기 1차 시기에 상기 애플리케이션의 상기 제1 상태를 결정하는 것에 응답하여, 상기 1차 시기에 상기 디바이스 상에 존재하지 않고 상기 애플리케이션과 연관된, 복수의 주문형 리소스(on demand resource) 중 제1 주문형 리소스를 요청하는 단계 -
   상기 애플리케이션의 상기 제1 상태가 제1 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 제1 리소스를 포함하고,
   상기 애플리케이션의 상기 제1 상태가 상기 제1 상태 기준과 상이한 제2 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 상기 제1 리소스와 상이한 제2 리소스를 포함하고,
   상기 애플리케이션의 상기 제1 상태는 상기 제1 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
   상기 네트워크 소스로부터 상기 복수의 주문형 리소스 중 제2 주문형 리소스를 수신하지 않으면서, 상기 제1 주문형 리소스를 수신하는 단계; 및
   상기 애플리케이션에 상기 제1 주문형 리소스를 로딩하는 단계를 포함하는, 컴퓨터 구현 방법.
2. 제1항에 있어서, 상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 제2 상태를 결정하는 단계;
   상기 2차 시기에 상기 애플리케이션의 상기 제2 상태를 결정하는 것에 응답하여, 상기 복수의 주문형 리소스 중 상기 제2 주문형 리소스를 요청하는 단계 -
   상기 애플리케이션의 상기 제2 상태가 제3 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 제3 리소스를 포함하고,
   상기 애플리케이션의 상기 상태가 상기 제3 상태 기준과 상이한 제4 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 상기 제3 리소스와 상이한 제4 리소스를 포함하고,
   상기 애플리케이션의 상기 제2 상태는 상기 제2 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
   상기 네트워크 소스로부터 상기 제2 주문형 리소스를 수신하는 단계; 및
   상기 애플리케이션에 상기 제2 주문형 리소스를 로딩하는 단계를 추가로 포함하는, 컴퓨터 구현 방법.
3. 제1항에 있어서, 상기 제1 주문형 리소스를 요청하기 전에 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능한지 확인하는 단계를 포함하고, 상기 제1 주문형 리소스를 요청하는 것은 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능하지 않다는 결정에 대한 응답인, 컴퓨터 구현 방법.
4. 제1항에 있어서,
   자산 팩 목록(asset pack manifest)이 상기 디바이스 상에서 이용가능한지 결정하는 단계 - 상기 자산 팩 목록은 상기 제1 주문형 리소스의 어드레스를 포함함 -;
   상기 자산 팩 목록을 획득하는 단계; 및
   상기 자산 팩 목록 내의 상기 어드레스를 이용하여 상기 제1 주문형 리소스를 요청하는 단계를 포함하는, 컴퓨터 구현 방법.
5. 제1항에 있어서, 상기 애플리케이션의 상기 상태에 기초하여 상기 제1 주문형 리소스를 포함하는 복수의 주문형 리소스가 요청되는 순서를 결정하는 단계를 포함하는, 컴퓨터 구현 방법.
6. 제1항에 있어서,
   상기 디바이스에서 저장 공간의 부족이 검출되는지 결정하는 단계;
   상기 디바이스에서 저장 공간의 부족이 검출되는 경우 상기 디바이스로부터 제거될 상기 애플리케이션의 적어도 하나의 주문형 리소스를 결정하는 단계; 및
   상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안 상기 디바이스로부터 상기 적어도 하나의 주문형 리소스를 제거하는 단계를 포함하는, 컴퓨터 구현 방법.
7. 제6항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션의 상기 상태에 기초하는, 컴퓨터 구현 방법.
8. 제6항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 사전결정된 복수의 주문형 리소스의 제거 순서에 기초하는, 컴퓨터 구현 방법.
9. 제6항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션과 연관된 사용 패턴에 기초하는, 컴퓨터 구현 방법.
10. 비일시적 컴퓨터 판독가능 매체로서, 상기 컴퓨터 판독가능 매체는, 실행 시, 디바이스 상에서 애플리케이션을 실행하는 방법을 수행하는 명령어들을 포함하고, 상기 방법은,
    네트워크 소스로부터 상기 애플리케이션의 앱 시작 번들을 획득하는 단계;
    상기 앱 시작 번들을 이용하여 상기 애플리케이션을 설치하는 단계;
    1차 시기에 상기 애플리케이션의 제1 상태를 결정하는 단계;
    상기 1차 시기에 상기 애플리케이션의 상기 제1 상태를 결정하는 것에 응답하여, 상기 1차 시기에 상기 디바이스 상에 존재하지 않고 상기 애플리케이션과 연관된, 복수의 주문형 리소스 중 제1 주문형 리소스를 요청하는 단계 -
    상기 애플리케이션의 상기 제1 상태가 제1 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 제1 리소스를 포함하고,
    상기 애플리케이션의 상기 제1 상태가 상기 제1 상태 기준과 상이한 제2 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 상기 제1 리소스와 상이한 제2 리소스를 포함하고,
    상기 애플리케이션의 상기 제1 상태는 상기 제1 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
    상기 네트워크 소스로부터 상기 복수의 주문형 리소스 중 제2 주문형 리소스를 수신하지 않으면서, 상기 제1 주문형 리소스를 수신하는 단계; 및
    상기 애플리케이션에 상기 제1 주문형 리소스를 로딩하는 단계를 포함하는, 비일시적 컴퓨터 판독가능 매체.
11. 제10항에 있어서, 상기 방법은,
    상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 제2 상태를 결정하는 단계;
    상기 2차 시기에 상기 애플리케이션의 상기 제2 상태를 결정하는 것에 응답하여, 상기 복수의 주문형 리소스 중 상기 제2 주문형 리소스를 요청하는 단계 -
    상기 애플리케이션의 상기 제2 상태가 제3 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 제3 리소스를 포함하고,
    상기 애플리케이션의 상기 상태가 상기 제3 상태 기준과 상이한 제4 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 상기 제3 리소스와 상이한 제4 리소스를 포함하고,
    상기 애플리케이션의 상기 제2 상태는 상기 제2 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
    상기 네트워크 소스로부터 상기 제2 주문형 리소스를 수신하는 단계; 및
    상기 애플리케이션에 상기 제2 주문형 리소스를 로딩하는 단계를 추가로 포함하는, 비일시적 컴퓨터 판독가능 매체.
12. 제10항에 있어서, 상기 방법은, 상기 제1 주문형 리소스를 요청하기 전에 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능한지 확인하는 단계를 추가로 포함하고, 상기 제1 주문형 리소스를 요청하는 것은 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능하지 않다는 결정에 대한 응답인, 비일시적 컴퓨터 판독가능 매체.
13. 제10항에 있어서, 상기 방법은,
    자산 팩 목록이 상기 디바이스 상에서 이용가능한지 결정하는 단계 - 상기 자산 팩 목록은 상기 제1 주문형 리소스의 어드레스를 포함함 -;
    상기 자산 팩 목록을 획득하는 단계; 및
    상기 자산 팩 목록 내의 상기 어드레스를 이용하여 상기 제1 주문형 리소스를 요청하는 단계를 추가로 포함하는, 비일시적 컴퓨터 판독가능 매체.
14. 제10항에 있어서, 상기 방법은, 상기 애플리케이션의 상기 상태에 기초하여 상기 제1 주문형 리소스를 포함하는 복수의 주문형 리소스가 요청되는 순서를 결정하는 단계를 추가로 포함하는, 비일시적 컴퓨터 판독가능 매체.
15. 제10항에 있어서, 상기 방법은,
    상기 디바이스에서 저장 공간의 부족이 검출되는지 결정하는 단계;
    상기 디바이스에서 저장 공간의 부족이 검출되는 경우 상기 디바이스로부터 제거될 상기 애플리케이션의 적어도 하나의 주문형 리소스를 결정하는 단계; 및
    상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안 상기 디바이스로부터 상기 적어도 하나의 주문형 리소스를 제거하는 단계를 추가로 포함하는, 비일시적 컴퓨터 판독가능 매체.
16. 제15항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션의 상기 상태에 기초하는, 비일시적 컴퓨터 판독가능 매체.
17. 제15항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 사전결정된 복수의 주문형 리소스의 제거 순서에 기초하는, 비일시적 컴퓨터 판독가능 매체.
18. 제15항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션과 연관된 사용 패턴에 기초하는, 비일시적 컴퓨터 판독가능 매체.
19. 시스템으로서,
    하나 이상의 프로세서;
    메모리; 및
    하나 이상의 프로그램을 포함하고, 상기 하나 이상의 프로그램은 상기 메모리에 저장되고 상기 하나 이상의 프로세서에 의해 실행되도록 구성되고, 상기 하나 이상의 프로세서에 의해 실행 시, 상기 시스템으로 하여금 디바이스 상에서 애플리케이션을 실행하는 방법을 수행하게 하고, 상기 방법은,
    네트워크 소스로부터 상기 애플리케이션의 앱 시작 번들을 획득하는 단계;
    상기 앱 시작 번들을 이용하여 상기 애플리케이션을 설치하는 단계;
    1차 시기에 상기 애플리케이션의 제1 상태를 결정하는 단계;
    상기 1차 시기에 상기 애플리케이션의 상기 제1 상태를 결정하는 것에 응답하여, 상기 1차 시기에 상기 디바이스 상에 존재하지 않고 상기 애플리케이션과 연관된, 복수의 주문형 리소스 중 제1 주문형 리소스를 요청하는 단계 -
    상기 애플리케이션의 상기 제1 상태가 제1 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 제1 리소스를 포함하고,
    상기 애플리케이션의 상기 제1 상태가 상기 제1 상태 기준과 상이한 제2 상태 기준을 충족한다는 결정에 따라, 상기 제1 주문형 리소스는 상기 제1 리소스와 상이한 제2 리소스를 포함하고,
    상기 애플리케이션의 상기 제1 상태는 상기 제1 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
    상기 네트워크 소스로부터 상기 복수의 주문형 리소스 중 제2 주문형 리소스를 수신하지 않으면서, 상기 제1 주문형 리소스를 수신하는 단계; 및
    상기 애플리케이션에 상기 제1 주문형 리소스를 로딩하는 단계를 포함하는, 시스템.
20. 제19항에 있어서, 상기 방법은,
    상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 제2 상태를 결정하는 단계;
    상기 2차 시기에 상기 애플리케이션의 상기 제2 상태를 결정하는 것에 응답하여, 상기 복수의 주문형 리소스 중 상기 제2 주문형 리소스를 요청하는 단계 -
    상기 애플리케이션의 상기 제2 상태가 제3 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 제3 리소스를 포함하고,
    상기 애플리케이션의 상기 상태가 상기 제3 상태 기준과 상이한 제4 상태 기준을 충족한다는 결정에 따라, 상기 제2 주문형 리소스는 상기 제3 리소스와 상이한 제4 리소스를 포함하고,
    상기 애플리케이션의 상기 제2 상태는 상기 제2 주문형 리소스에 대응하는 상기 애플리케이션의 일부분을 실행하기 위한 상기 디바이스에 대한 사용자 입력에 독립적임 -;
    상기 네트워크 소스로부터 상기 제2 주문형 리소스를 수신하는 단계; 및
    상기 애플리케이션에 상기 제2 주문형 리소스를 로딩하는 단계를 추가로 포함하는, 시스템.
21. 제19항에 있어서, 상기 방법은, 상기 제1 주문형 리소스를 요청하기 전에 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능한지 확인하는 단계를 추가로 포함하고, 상기 제1 주문형 리소스를 요청하는 것은 상기 제1 주문형 리소스가 상기 디바이스 상에서 이용가능하지 않다는 결정에 대한 응답인, 시스템.
22. 제19항에 있어서, 상기 방법은,
    자산 팩 목록이 상기 디바이스 상에서 이용가능한지 결정하는 단계 - 상기 자산 팩 목록은 상기 제1 주문형 리소스의 어드레스를 포함함 -;
    상기 자산 팩 목록을 획득하는 단계; 및
    상기 자산 팩 목록 내의 상기 어드레스를 이용하여 상기 제1 주문형 리소스를 요청하는 단계를 추가로 포함하는, 시스템.
23. 제19항에 있어서, 상기 방법은, 상기 애플리케이션의 상기 상태에 기초하여 상기 제1 주문형 리소스를 포함하는 복수의 주문형 리소스가 요청되는 순서를 결정하는 단계를 추가로 포함하는, 시스템.
24. 제19항에 있어서, 상기 방법은,
    상기 디바이스에서 저장 공간의 부족이 검출되는지 결정하는 단계;
    상기 디바이스에서 저장 공간의 부족이 검출되는 경우 상기 디바이스로부터 제거될 상기 애플리케이션의 적어도 하나의 주문형 리소스를 결정하는 단계; 및
    상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안 상기 디바이스로부터 상기 적어도 하나의 주문형 리소스를 제거하는 단계를 추가로 포함하는, 시스템.
25. 제24항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션의 상기 상태에 기초하는, 시스템.
26. 제24항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 사전결정된 복수의 주문형 리소스의 제거 순서에 기초하는, 시스템.
27. 제24항에 있어서, 제거될 적어도 하나의 주문형 리소스를 결정하는 것은, 적어도 부분적으로, 상기 애플리케이션과 연관된 사용 패턴에 기초하는, 시스템.
28. 제1항에 있어서, 상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안,
    상기 1차 시기에, 상기 애플리케이션의 주문형 리소스들의 제1 세트가 상기 디바이스 상에 있고,
    상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 주문형 리소스들의 제2 세트가 상기 디바이스 상에 있고, 주문형 리소스들의 상기 제1 세트는 주문형 리소스들의 상기 제2 세트에 포함되지 않은 주문형 리소스를 포함하는, 컴퓨터 구현 방법.
29. 제10항에 있어서, 상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안,
    상기 1차 시기에, 상기 애플리케이션의 주문형 리소스들의 제1 세트가 상기 디바이스 상에 있고,
    상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 주문형 리소스들의 제2 세트가 상기 디바이스 상에 있고, 주문형 리소스들의 상기 제1 세트는 주문형 리소스들의 상기 제2 세트에 포함되지 않은 주문형 리소스를 포함하는, 비일시적 컴퓨터 판독가능 매체.
30. 제19항에 있어서, 상기 애플리케이션이 상기 디바이스 상에서 실행되고 있는 동안,
    상기 1차 시기에, 상기 애플리케이션의 주문형 리소스들의 제1 세트가 상기 디바이스 상에 있고,
    상기 1차 시기 이후의 2차 시기에, 상기 애플리케이션의 주문형 리소스들의 제2 세트가 상기 디바이스 상에 있고, 주문형 리소스들의 상기 제1 세트는 주문형 리소스들의 상기 제2 세트에 포함되지 않은 주문형 리소스를 포함하는, 시스템.

Images