KR101882469B1

KR101882469B1 - 피어 이벤트 데이터에 기초한 모바일 디바이스의 동적 조정

Info

Publication number: KR101882469B1
Application number: KR1020167036445A
Authority: KR
Inventors: 조나단 제이. 앤드류즈; 다니엘 벤 폴락; 휴 듀크 트란; 조아오 페드로 포르자즈 데 라세르다
Original assignee: 애플 인크.
Priority date: 2014-05-30
Filing date: 2015-05-07
Publication date: 2018-07-27
Also published as: US20150350807A1; KR20180086517A; KR20170012427A; US20170078445A1; US10554786B2; CN111176698B; US10178200B2; KR102106744B1; CN111176698A; CN106462453A; KR20180086515A; US9432796B2; KR20180086516A; US20190109927A1; KR101996263B1; KR20190080969A; KR101993569B1; KR101993568B1; CN106462453B; WO2015183515A1

Abstract

일부 구현들에서, 모바일 디바이스는 모바일 디바이스 및/또는 피어 디바이스와 연관된 환경, 시스템 및 사용자 이벤트들을 모니터링하도록 구성될 수 있다. 하나 이상의 이벤트의 발생은 시스템 설정에 대한 조정을 트리거할 수 있다. 모바일 디바이스는 사용자에 의한 예상된 호출의 예측에 기초하여 자주 호출된 애플리케이션들을 최신으로 유지하도록 구성될 수 있다. 일부 구현들에서, 모바일 디바이스는, 신규 콘텐츠가 애플리케이션들이 다운로드하는 데 이용 가능하다는 것을 나타내는, 애플리케이션들과 연관된 푸시 통지들을 수신할 수 있다. 모바일 디바이스는 푸시 통지들과 연관된 애플리케이션들을 백그라운드에서 개시하고 신규 콘텐츠를 다운로드할 수 있다. 애플리케이션을 실행하거나 피어 디바이스와 통신하기 전에, 모바일 디바이스는 모바일 디바이스 및/또는 피어 디바이스의 에너지 및 데이터 예산들 및 환경 조건들을 체크하여 고품질의 사용자 경험을 보장하도록 구성될 수 있다.

Description

피어 이벤트 데이터에 기초한 모바일 디바이스의 동적 조정{DYNAMIC ADJUSTMENT OF MOBILE DEVICE BASED ON PEER EVENT DATA}

본 개시내용은 일반적으로 시스템 이벤트에 기초하여 시스템 리소스를 관리하는 것에 관한 것이다.

모바일 컴퓨팅 디바이스는 전형적으로 배터리로 작동된다. 일부 모바일 컴퓨팅 디바이스들은 셀룰러 데이터 및/또는 Wi-Fi 네트워크 연결들을 통해 네트워크 리소스들에 무선으로 액세스할 수 있다. 이러한 모바일 디바이스들은 종종 배터리 용량 및/또는 셀룰러 데이터 사용량에 대한 제한에 의해 제약을 받을 수 있다.

일부 모바일 컴퓨팅 디바이스들은 사용자로 하여금 네트워크 리소스들로부터의 데이터에 액세스하는 애플리케이션들을 실행할 수 있게 한다. 사용자는, 전형적으로 애플리케이션이 현재 업데이트된 콘텐츠를 보여줄 수 있도록, 애플리케이션을 호출하고, 이어서 애플리케이션이 네트워크 리소스들로부터 데이터를 검색하기를 기다려야만 한다.

일부 구현들에서, 모바일 디바이스는 환경, 시스템 및 사용자 이벤트들을 모니터링하도록 구성될 수 있다. 모바일 디바이스는 시스템 설정에 대한 조정을 트리거할 수 있는 하나 이상의 이벤트의 발생을 검출하도록 구성될 수 있다.

일부 구현들에서, 모바일 디바이스는 미리정의된 그리고/동적으로 정의된 속성들로 구성될 수 있다. 속성들은 시스템 이벤트들을 추적하기 위해 시스템에 의해 사용될 수 있다. 속성 이벤트들은 저장될 수 있고, 나중에 속성 이벤트들의 향후 발생들을 예측하는 데 사용될 수 있다. 저장된 속성 이벤트들은 모바일 디바이스에 의해 수행되는 처리에 관한 결정들을 하기 위해 시스템에 의해 사용될 수 있다. 속성들은 시스템 상의 향후 이벤트들 또는 활동들을 지원하도록 리소스들의 예산책정을 허용하는 예산들과 연관될 수 있다.

일부 구현들에서, 모바일 디바이스 상에서 실행되는 다양한 애플리케이션들, 기능들 및 프로세스들은 속성 이벤트들을 제출할 수 있다. 애플리케이션들, 기능들 및 프로세스들은 나중에, 제출된 이벤트들에 기초하여 예측들을 요청할 수 있다. 애플리케이션들, 기능들 및 프로세스들은 속성들과 연관된 예산들 및 보고된 이벤트들과 연관된 비용들에 기초하여 예산책정을 수행할 수 있다. 애플리케이션들, 기능들 및 프로세스들은 예를 들어, 모바일 디바이스의 운영 체제 또는 제3자 애플리케이션과 연관될 수 있다.

일부 구현들에서, 모바일 디바이스는 자주 호출된 애플리케이션들을 최신으로 유지하도록 구성될 수 있다. 모바일 디바이스는 애플리케이션들이 언제 사용자에 의해 호출되는지를 추적할 수 있다. 호출 정보에 기초하여, 모바일 디바이스는 애플리케이션들이 하루 중 언제 호출되는지를 예측할 수 있다. 이어서, 모바일 디바이스는, 사용자가 애플리케이션들을 호출하고 업데이트된 콘텐츠를 애플리케이션이 다운로드하기를 기다릴 필요 없이 현재 업데이트된 콘텐츠를 볼 수 있도록, 우선적으로 애플리케이션들을 개시하고 업데이트들을 다운로드할 수 있다.

일부 구현들에서, 모바일 디바이스는, 신규 콘텐츠가 애플리케이션들이 다운로드하는 데 이용 가능하다는 것을 나타내는, 애플리케이션들과 연관된 푸시 통지들을 수신할 수 있다. 모바일 디바이스는 푸시 통지들과 연관된 애플리케이션들을 백그라운드에서 개시하고 신규 콘텐츠를 다운로드할 수 있다. 콘텐츠가 다운로드된 후에, 모바일 디바이스는 푸시 통지가 수신되었음을 사용자에게 나타내는 그래픽 인터페이스를 보여줄 수 있다. 이어서, 사용자는 애플리케이션들을 호출하고 업데이트된 콘텐츠를 볼 수 있다.

일부 구현들에서, 모바일 디바이스는 모바일 디바이스 상의 애플리케이션들에 대한 콘텐츠의 다운로드들 및/또는 업로드들을 프로세스를 벗어나서 수행하도록 구성될 수 있다. 예를 들면, 전용 프로세스는 모바일 디바이스 상의 애플리케이션들에 대한 콘텐츠를 다운로드하고/하거나 업로드하기 위하여 모바일 디바이스 상에 구성될 수 있다. 애플리케이션들은 업로드/다운로드가 수행되는 동안 보류되거나 종료될 수 있다. 애플리케이션들은 업로드/다운로드가 완료될 때 호출될 수 있다.

일부 구현들에서, 애플리케이션을 실행하거나 네트워크 인터페이스에 액세스하기 전에, 모바일 디바이스는 배터리 전력 및 셀룰러 데이터 사용 예산들을 체크하여 충분한 전력 및 데이터가 사용자 호출된 동작(user invoked operation)들에 이용 가능하다는 것을 보장하도록 구성될 수 있다. 백그라운드에서 애플리케이션을 개시하기 전에, 모바일 디바이스는 사용 통계치를 체크하여 애플리케이션이 가까운 미래에 사용자에 의해 호출될 가능성이 있는지 여부를 결정할 수 있다.

일부 구현들에서, 속성 이벤트 데이터는 동일한 사용자에 의해 소유된 모바일 디바이스들 사이에서 공유될 수 있다. 모바일 디바이스는 피어 디바이스로부터 이벤트 데이터를 수신하고, 수신된 이벤트 데이터에 기초하여 피어 디바이스와 관련된 상호작용들 또는 동작들에 관한 결정들을 할 수 있다. 이벤트 데이터는 예측, 통계치, 및/또는 원시(예를 들어, 미처리된) 이벤트 데이터로서 공유될 수 있다. 모바일 디바이스는 예를 들어, 수신된 이벤트 데이터에 기초하여 피어 디바이스와 통신할지 여부를 결정할 수 있다.

특정 구현들은 적어도 하기의 이점들을 제공한다: 검출된 이벤트들에 응답하여 모바일 디바이스의 컴포넌트들을 동적으로 조정함으로써 배터리 전력이 보존될 수 있다. 사용자가 언제 애플리케이션들을 호출할지를 예상하고, 애플리케이션을 호출하면 사용자가 업데이트된 콘텐츠를 보도록 콘텐츠를 다운로드함으로써, 사용자 경험이 향상될 수 있다.

하나 이상의 구현들의 상세 사항들이 첨부 도면 및 이하의 설명에서 제시된다. 다른 특징들, 양태들, 잠재적 이점들이 설명 및 도면으로부터 그리고 청구범위로부터 명백해질 것이다.

도 1은 모바일 디바이스의 동적 조정을 수행하도록 구성된 모바일 디바이스를 예시한다.
도 2는 휴리스틱 프로세스(heuristic process)들을 호출하기 위한 예시적인 프로세스를 예시한다.
도 3은 휴리스틱 프로세스를 사용하여 모바일 디바이스의 설정을 조정하기 위한 프로세스를 예시한다.
도 4는 애플리케이션들의 백그라운드 페치 업데이트(background fetch updating)를 수행하기 위한 예시적인 시스템을 예시한다.
도 5는 모바일 디바이스(100) 상의 애플리케이션들에 대한 사용자 호출 확률들을 결정하기 위한 피어 예측을 예시한다.
도 6은 백그라운드 업데이트들을 수행하기 위하여 애플리케이션들을 예측적으로 개시하기 위한 예시적인 프로세스의 흐름도이다.
도 7은 모바일 디바이스 상에서 애플리케이션들을 언제 개시할지를 결정하기 위한 예시적인 프로세스의 흐름도이다.
도 8은 트렌딩 표(trending table)에서의 엔트리(entry)에 대한 상태 전이들을 예시하는 흐름도이다.
도 9는 모바일 디바이스에 푸시 통지들을 제공하기 위한 시스템을 예시하는 블록도이다.
도 10은 푸시 통지 서버에서 비웨이킹 푸시(non-waking push)들을 수행하기 위한 예시적인 프로세스의 흐름도이다.
도 11은 낮은 우선순위 푸시 통지에 응답하여 애플리케이션의 백그라운드 업데이트를 수행하기 위한 예시적인 프로세스의 흐름도이다.
도 12는 높은 우선순위 푸시 통지에 응답하여 애플리케이션의 백그라운드 업데이트를 수행하기 위한 예시적인 프로세스의 흐름도이다.
도 13은 모바일 디바이스 상에서 데이터의 백그라운드 다운로드 및/또는 업로드를 수행하기 위한 예시적인 시스템의 블록도이다.
도 14는 백그라운드 다운로드 및 업로드를 수행하기 위한 예시적인 프로세스의 흐름도이다.
도 15는 모바일 디바이스 상에서 애플리케이션들에 대한 백그라운드 업데이트들을 인에이블 및/또는 디스에이블하기 위한 예시적인 그래픽 사용자 인터페이스(GUI)를 예시한다.
도 16은 피어 디바이스들 사이에서 데이터를 공유하기 위한 예시적인 시스템을 예시한다.
도 17은 피어 디바이스들 사이에서 데이터를 공유하기 위한 예시적인 프로세스를 예시한다.
도 18은 도 1 내지 도 17의 특징들 및 프로세스들을 구현할 수 있는 예시적인 컴퓨팅 디바이스의 블록도이다.
다양한 도면들에서의 유사한 도면 부호들은 유사한 요소들을 가리킨다.

개요

배터리 수명, 전력 요건들, 열 관리 및 성능 사이에서 절충(tradeoff)을 용이하게 하도록 다양한 시스템 이벤트들에 기초하여 모바일 디바이스의 적용을 가능하게 하는 시스템 아키텍처가 본 명세서에서 기술된다. 시스템은 시스템 이벤트들로부터 학습하는 휴리스틱 프로세스들의 세트 및 기반 이벤트(underlying event) 수집 아키텍처를 제공하여, 사용자 경험의 현저한 저하 없이 배터리 수명을 최대화한다. 시스템은 시스템 정의된 속성 및 클라이언트 정의된 속성을 모니터링하고, 시스템 정의된 속성 및 클라이언트 정의된 속성을 사용하여 향후 이벤트들의 발생을 예상하거나 예측할 수 있다. 이러한 시스템은 동적으로 수집된 통계치 및/또는 명확하게 특정된 사용자 의도에 기초하여 디바이스 성능에 대한 사용자의 기대뿐만 아니라 시스템의 향후 행동을 예상할 수 있다. 시스템은 예상된 시스템 행동에 대한 사용자 경험을 향상시키기 위하여 어느 하드웨어 및 소프트웨어 제어 파라미터들을 설정할지 그리고 그 파라미터들을 어떤 값들로 설정할지를 결정할 수 있다. 시스템은 시스템 모니터링 및 하드웨어 제어를 레버리징(leverage)하여, 모바일 디바이스에 이용 가능한 시스템 및 네트워크 리소스들을 확장하면서 사용자 경험에서의 전체적인 향상을 달성한다. 따라서, 시스템은 사용자 경험에 대한 영향을 최소화하면서 시스템 및 네트워크 리소스들을 최대화할 수 있다.

데이터 수집 ― 사용자 중심 통계치

도 1은 모바일 디바이스(100)의 동적 조정을 수행하도록 구성된 예시적인 모바일 디바이스(100)를 예시한다. 일부 구현들에서, 모바일 디바이스(100)는 디바이스 상태, 네트워크 상태, 시스템 서비스(예를 들어, 데몬(daemon)) 및 사용자 행동에 관련된 이벤트들을 수집하는 샘플링 데몬(102)을 포함할 수 있다. 예를 들면, 샘플링 데몬(102)은 애플리케이션, 센서 및 모바일 디바이스(100)에 의해 수신된 사용자 입력에 관련된 통계치를 수집하고 통계치를 이벤트 데이터 저장소(104)에 저장할 수 있다. 통계치는, 이벤트로서 보고된 미리정의된 또는 클라이언트 정의된 속성들을 사용하여 모바일 디바이스(100) 상에서 실행되는 다양한 클라이언트들(예를 들어, 애플리케이션, 유틸리티, 기능, 제3자 애플리케이션 등)에 의해 샘플링 데몬(102)에 보고될 수 있다.

데이터 수집 - 이벤트 및 속성

일부 구현들에서, 모바일 디바이스(100)는 시스템 및/또는 애플리케이션 이벤트들을 수집하기 위한 프레임워크로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)는, 모바일 디바이스(100)의 다양한 애플리케이션들, 유틸리티들 및 다른 컴포넌트들이 나중의 통계 분석을 위해 샘플링 데몬(102)에 이벤트들을 제출할 수 있게 하는, API(Application Programming Interface)들로 구성될 수 있다.

일부 구현들에서, 샘플링 데몬(102)에 의해 이벤트 데이터 저장소(104)에 기록된 각각의 이벤트는, 속성 이름(예를 들어, "bundleId"), 속성 값(예를 들어, "contacts"), 익명화된 비콘 정보, 익명화된 위치 정보, 날짜 정보(예를 들어, 이벤트의 GMT 날짜), 시간 정보(예를 들어, 이벤트의 현지화된 24시간), 네트워크 품질 정보, 프로세서 이용 메트릭, 디스크 입력/출력 메트릭, 현재 사용자의 식별 및/또는 이벤트의 유형(예를 들어, 시작, 중지, 발생함)을 포함할 수 있다. 예를 들어, 속성 이름은 이벤트와 연관된 속성의 유형을 식별할 수 있다. 속성 이름은 예를 들어, 샘플링 데몬(102)에 의해 추적되는 특정 메트릭을 식별하는 데 사용될 수 있다. 속성 값은 속성과 연관된 값(예를 들어, 문자열, 정수, 부동 소수점)일 수 있다. 익명화된 비콘 정보는, 비콘 정보를 사용자 또는 디바이스에 묶거나 연관시키지 않고 모바일 디바이스의 범위 내에 어느 무선 비콘들(예를 들어, 블루투스, 저전력 블루투스(Bluetooth Low Energy), Wi-Fi 등)이 있는지를 나타낼 수 있다. 유사하게, 익명화된 위치 정보는 사용자 또는 디바이스에 위치 정보를 묶거나 연관시키지 않고 모바일 디바이스의 위치를 식별할 수 있다. 예를 들어, 위치 정보는 모바일 디바이스(100) 상에 구성된 다양한 송수신기들을 사용하여 위성 데이터(예를 들어, 글로벌 포지셔닝 위성 시스템), 셀룰러 데이터, Wi-Fi 데이터, 블루투스 데이터로부터 도출될 수 있다. 네트워크 품질 정보는 이벤트가 발생했을 때 모바일 디바이스(100)에 의해 검출되는 모바일 디바이스의 네트워크(예를 들어, Wi-Fi, 셀룰러, 위성 등) 연결의 품질을 나타낼 수 있다.

일부 구현들에서, 각 이벤트에 대한 이벤트 데이터는 이벤트가 발생, 시작 또는 중지되었음을 나타낼 수 있다. 예를 들어, 시간 어카운팅(time accounting)(예를 들어, 지속기간 어카운팅)이 속성에 대한 시작 이벤트 및 중지 이벤트를 나타내는 동일한 속성에 대한 이벤트들의 쌍들에 대해 수행될 수 있다. 예를 들어, 샘플링 데몬(102)은 값 "contacts"를 갖는 속성 "bundleId"에 대한 시작 이벤트를 수신할 수 있다. 나중에, 샘플링 데몬(102)은 값 "contacts"를 갖는 속성 "bundleId"에 대한 중지 이벤트를 수신할 수 있다. 샘플링 데몬(102)은 시작 이벤트의 시간을 중지 이벤트의 시간과 비교하여 "contacts" 애플리케이션이 얼마나 오랫동안 활성 상태였는지를(예를 들어, 지속기간) 결정할 수 있다. 일부 구현들에서, 시간 어카운팅의 대상이 아닌 이벤트들은 포인트 이벤트들(예를 들어, 단일 발생)로서 기록될 수 있다. 예를 들어, 이벤트의 시간에서 순간 배터리 레벨을 특정하는 "batteryLevel" 시스템 속성과 연관된 이벤트는 단순히 이벤트의 발생으로서 기록될 수 있다.

아래의 표 1은 샘플링 데몬(102)에 의해 이벤트 데이터 저장소(104)에 기록된 속성 이벤트 엔트리들의 예를 제공한다. 첫 번째 엔트리는 "contacts" 애플리케이션이 사용자 "Fred"에 의해 호출되었음을 나타내는 "bundleId" 이벤트를 기록한다. 이 "bundleId" 이벤트는 Fred가 연락처 애플리케이션을 사용하기 시작했음을 나타내는 시작 이벤트이다. 두 번째 엔트리는 모바일 디바이스(100)의 배터리 레벨이 46%임을 나타내는 "batteryLevel" 이벤트 엔트리이고; 이 이벤트는 발생 유형 이벤트(예를 들어, 단일 포인트 이벤트)이다. 세 번째 엔트리는 값 "George"와 연관된 "personName" 이벤트이다. "personName" 이벤트는 사용자 Fred가 연락처 애플리케이션에서 연락처 "George"에 대한 연락처 정보에 액세스했다는 사실을 기록하는 데 사용되며; 이는 발생 유형 이벤트이다. 네 번째 엔트리는 "contacts" 애플리케이션이 사용자 "Fred"에 의해 닫혔거나 숨겨졌음을 나타내는 "bundleId" 이벤트를 기록한다. 이 bundleId 이벤트는 Fred가 연락처 애플리케이션을 사용하는 것을 중지했음을 나타내는 중지 이벤트이다. "bundleId" 속성에 대한 시작 및 중지 이벤트들을 기록함으로써, 샘플링 데몬(102)은 사용자 Fred가 시작 및 중지 이벤트들에 대응하는 타임스탬프들에 기초하여 2014년 5월 12일에 8분 동안 연락처 애플리케이션을 사용했음을 결정할 수 있다. 이 속성 이벤트 정보는 예를 들어, 모바일 디바이스(100) 상의 애플리케이션들에 관련된 그리고 특히 연락처 애플리케이션에 관한 사용자 활동을 예측하는 데 사용될 수 있다.

[표 1]

미리정의된 속성

일부 구현들에서, 이벤트 데이터는 잘 알려진 또는 미리정의된 속성들을 사용하여 샘플링 데몬(102)에 제출될 수 있다. 잘 알려진 또는 미리정의된 속성들은 이벤트 데이터를 샘플링 데몬(102)에 제출하기 위해 모바일 디바이스(100)의 다양한 애플리케이션들, 유틸리티들, 기능들 또는 다른 컴포넌트들에 의해 사용될 수 있는 일반적인 시스템 속성들일 수 있다. 속성 정의(예를 들어, 속성 이름, 연관된 값의 데이터 유형 등)가 미리 정의되어 있지만, 미리정의된 속성에 할당되는 값들은 이벤트마다 다를 수 있다. 예를 들어, 모바일 디바이스(100)는 미리정의된 속성들인, 애플리케이션들을 식별하기 위한 "bundleId" 및 관심 대상인 사람들을 식별하기 위한 "personName"으로 구성될 수 있다. "bundleId"에 할당된 값들은 모바일 디바이스(100) 상에서 어느 애플리케이션이 활성 상태인지에 기초하여 달라질 수 있다. "personName"에 할당된 값들은 사용자 입력에 기초하여 달라질 수 있다. 예를 들어 사용자가 "George"로부터의 이메일 메시지를 선택하는 경우, "personName" 속성 값은 "George"로 설정될 수 있다. 사용자가 "Bob"과 연관된 연락처 엔트리를 선택하는 경우, "personName" 속성 값은 "Bob"으로 설정될 수 있다. 모바일 디바이스(100)의 애플리케이션, 유틸리티, 기능 또는 다른 컴포넌트가 미리정의된 속성들을 사용하여 샘플링 데몬(102)에 이벤트를 제출하는 경우, 애플리케이션, 유틸리티, 기능 또는 다른 컴포넌트는 그 이벤트에 대한 미리정의된 속성과 연관될 값을 특정할 수 있다. 미리정의된 또는 잘 알려진 시스템 이벤트들의 예들이 하기의 단락들에서 설명된다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100) 상에 설치된 애플리케이션(예를 들어, 애플리케이션 번들)에 대한 이름 또는 식별자를 특정하는 미리정의된 속성(예를 들어, "system.bundleId")으로 구성될 수 있다. 애플리케이션이 시작될 때, 애플리케이션 관리자(106)(예를 들어, 애플리케이션들을 개시하는 것을 담당함)는 샘플링 데몬(102)의 API를 사용하여, 애플리케이션의 식별자 또는 이름(예를 들어, 연락처 애플리케이션에 대한 "contacts")을 "system.bundleId" 시스템 속성에 대한 값으로서 제출할 수 있다. 샘플링 데몬(102)은 "contacts" 애플리케이션의 개시의 발생을, 전술한 바와 같이, 예를 들어, 다른 이벤트 데이터와 함께, 이벤트 데이터 저장소(104) 내의 이벤트로서 기록할 수 있다. 대안적으로, 애플리케이션은 샘플링 데몬(102)의 API를 사용하여, 각각 애플리케이션 "contacts"가 호출될 때 및 애플리케이션이 숨겨지거나 닫힐 때에 대응하는 시작 및 중지 이벤트들을 나타낼 수 있다. 예를 들어, "bundleId" 속성은 모바일 디바이스(100) 상의 애플리케이션 개시 이벤트들을 기록하는 데 사용될 수 있다. "bundleId" 속성은 모바일 디바이스(100) 상의 애플리케이션 종료 이벤트들을 기록하는 데 사용될 수 있다. 단지 이벤트의 발생보다는, "bundleId" 속성과 연관된 시작 및 중지 이벤트들을 특정함으로써, 샘플링 데몬(102)은 모바일 디바이스(100)의 사용자에 의해 "contacts" 애플리케이션이 얼마나 오랫동안 사용되었는지를 결정할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 사용자 또는 모바일 디바이스(100)의 사용자의 관심 대상인 사람의 이름 또는 식별자를 특정하는 미리정의된 속성(예를 들어, "system.personName")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)에 로그인하거나, 웨이크하거나 다른 식으로 액세스하면, 모바일 디바이스(100)의 현재 사용자를 식별하는 "personName" 속성과 연관된 이벤트가 생성되어 샘플링 데몬(102)에 제출될 수 있다. 사용자가 다른 사람과 연관된 데이터에 액세스하는 경우, 다른 사람을 사용자의 관심 대상인 사람으로서 식별하는 "personName" 속성 이벤트가 생성되어 샘플링 데몬(102)에 제출될 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 위치를 나타내는 미리정의된 속성(예를 들어, "system.anonymizedLocation")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)는 이벤트가 생성될 때 모바일 디바이스(100)의 위치를 특정하는 "anonymizedLocation" 속성과 연관된 이벤트를 생성하여 샘플링 데몬(102)에 제출할 수 있다. 위치 데이터는, 위치가 나중에 특정 사용자 또는 디바이스에 묶이거나 연관될 수 없도록, 익명화될 수 있다. "anonymizedLocation" 속성 이벤트는 예를 들어, 사용자가 모바일 디바이스(100)의 위치-기반 서비스를 사용할 때마다 생성되고 저장될 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 에어플레인 모드가 온 또는 오프임을 나타내는 미리정의된 속성(예를 들어, "system.airplaneMode")으로 구성될 수 있다. 예를 들어, 사용자가 에어플레인 모드를 켜거나 끄는 경우, 모바일 디바이스(100)는 이벤트 시의 에어플레인 모드 상태를 나타내는 이벤트를 생성하여 샘플링 데몬(102)에 제출할 수 있다. 예를 들어, "airplaneMode" 속성의 값은 에어플레인 모드가 켜져 있을 때 참(예를 들어, 1)으로 설정되고, 에어플레인 모드가 오프일 때 거짓(예를 들어, 0)으로 설정될 수 있다. 샘플링 데몬(102)은 결국, "airplaneMode" 속성 값을 포함하는 "airplaneMode" 이벤트를 이벤트 데이터 저장소(104)에 저장할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 전력 케이블이 플러그인되거나 플러그인되지 않았음을 나타내는 미리정의된 속성(예를 들어, "system.cablePlugin")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)가 전력 케이블이 언플러그되었음을 검출할 때, 모바일 디바이스(100)는 "cablePlugin" 속성 값이 거짓(예를 들어, 0)임을 나타내는 이벤트를 생성할 수 있다. 모바일 디바이스(100)가 전력 케이블이 모바일 디바이스(100)에 플러그인되었음을 검출할 때, 모바일 디바이스(100)는 "cablePlugin" 속성이 참(예를 들어, 1)임을 나타내는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "cablePlugin" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 디스플레이 스크린이 잠겨 있는지 또는 잠금해제되어 있는지를 나타내는 미리정의된 속성(예를 들어, "system.screenLock")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)는 모바일 디바이스(100)의 디스플레이 스크린이 언제 (예를 들어, 시스템에 의해 또는 사용자에 의해) 잠기거나 (예를 들어, 사용자에 의해) 잠금해제되는지를 검출할 수 있다. 디스플레이 스크린의 잠금 또는 잠금해제를 검출하면, 모바일 디바이스(100)는 "screenLock" 속성을 포함하는 이벤트를 생성하고, 이벤트에 대한 "screenLock" 속성 값을 참(예를 들어, 잠김, 정수 1) 또는 거짓(예를 들어, 잠금해제됨, 정수 0)으로 설정하여 모바일 디바이스(100)의 디스플레이 스크린이 잠겼는지 또는 잠금해제되었는지 여부를 나타낼 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "screenLock" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)가 슬립 모드에 있는지 여부를 나타내는 미리정의된 속성(예를 들어, "system.sleepWake")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)는 모바일 디바이스(100)가 언제 슬립 모드에 진입하는지를 검출할 수 있다. 모바일 디바이스(100)는 모바일 디바이스(100)가 언제 슬립 모드를 종료하는지를(예를 들어, 웨이크) 검출할 수 있다. 슬립 모드에 진입하거나 종료하는 것을 검출하면, 모바일 디바이스는 "sleepWake" 속성을 포함하는 이벤트를 생성하고, "sleepWake" 이벤트 시 모바일 디바이스(100)의 슬립 모드 상태를 나타내기 위해 속성 값을 참 또는 거짓(예를 들어, 각각, 정수 1 또는 0)으로 설정한다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "sleepWake" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 디스플레이가 점등되어 있는지를 나타내는 미리정의된 속성(예를 들어, "system.backlight")으로 구성될 수 있다. "backlight" 속성은 백라이트의 세기 또는 레벨을 나타내는 값을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)의 사용자는 모바일 디바이스(100)의 디스플레이의 조명(백라이트)의 세기를 조정할 수 있다. 주변 조명이 밝을 때 사용자는 백라이트의 세기를 증가시킬 수 있다. 주변 조명이 어두울 때 사용자는 백라이트의 세기를 감소시킬 수 있다. 백라이트 설정의 변화를 검출하면, 모바일 디바이스(100)는 "backlight" 속성을 포함하는 이벤트를 생성할 수 있고, 속성 값을 조정된 백라이트 설정(예를 들어, 세기 레벨)으로 설정한다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "backlight" 변화 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 주변광 센서에 의해 검출된 주변광 세기 값을 나타내는 미리정의된 속성(예를 들어, "system.ALS")으로 구성될 수 있다. "ALS" 속성은 모바일 디바이스(100)를 둘러싸는 주변광의 세기 또는 레벨을 나타내는 값을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)의 주변광 센서는 주변광의 세기의 변화를 검출할 수 있다. 모바일 디바이스(100)는 세기의 변화가 소정 임계값을 초과함을 결정할 수 있다. 임계값을 초과하는 주변광의 변화를 검출하면, 모바일 디바이스(100)는, "ALS" 속성을 포함하고 속성 값을 검출된 주변광 세기 값으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "ALS" 변화 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는, 모바일 디바이스(100)의 근접 센서가 모바일 디바이스(100)의 디스플레이가 물체(예를 들어, 테이블 상에서, 사용자의 얼굴 등) 근처에 있음을 검출할 때를 나타내는 미리정의된 속성(예를 들어, "system.proximity")으로 구성될 수 있다. "proximity" 속성은 모바일 디바이스의 디스플레이가 물체에 근접해 있는지를 나타내는 값(예를 들어, 참, 거짓, 0, 1)을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)의 근접 센서는 근접의 변화를 검출할 수 있다. 근접의 변화를 검출하면, 모바일 디바이스(100)는, "proximity" 속성을 포함하고 모바일 디바이스(100)가 물체에 근접해 있을 때 속성 값을 참(예를 들어, 1)으로 설정하고 모바일 디바이스(100)가 물체에 근접해 있지 않을 때 거짓(예를 들어, 0)으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "proximity" 변화 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)에 의해 검출된 모션의 유형을 나타내는 미리정의된 속성(예를 들어, "system.motionState")으로 구성될 수 있다. "motionState" 속성은 모바일 디바이스가 정지 상태인지, 움직이는 중인지, 달리는 중인지, 운전 중인지, 걷는 중인지 등을 나타내는 값을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)의 모션 센서(예를 들어, 가속도계)는 모바일 디바이스(100)의 움직임을 검출할 수 있다. 모바일 디바이스(100)는 검출된 움직임에서 검출된 모션의 패턴들에 기초하여, 검출된 움직임을 분류할 수 있다. 모션의 패턴들은 사용자가 정지 상태일 때, 움직이는 중일 때, 달리는 중일 때, 운전 중일 때, 걷는 중일 때 등과 같은 사용자 활동들로 분류될 수 있다. 움직임의 변화를 검출하면, 모바일 디바이스(100)는, "motionState" 속성을 포함하고 속성 값을 검출된 움직임의 유형(예를 들어, 정지, 달리기, 걷기, 운전 등)으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "motionState" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)에 의해 검출된 네트워크 연결의 품질을 나타내는 미리정의된 속성(예를 들어, "system.networkQuality")으로 구성될 수 있다. "networkQuality" 속성은 n초(예를 들어, 1밀리초, 2밀리초 등)의 기간에 걸쳐 네트워크 처리량 값을 나타내는 값을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)는 데이터 네트워크(예를 들어, 셀룰러 데이터, 위성 데이터, Wi-Fi, 인터넷 등)에 연결될 수 있다. 모바일 디바이스(100)는 일정 기간(예를 들어, 5초)에 걸쳐 네트워크 연결의 데이터 처리량을 모니터링할 수 있다. 모바일 디바이스는 초당 전송되는 데이터의 양(예를 들어, 비트/초, 바이트/초 등)을 계산할 수 있다. 처리량의 변화를 검출하거나 신규 네트워크 연결을 생성하면, 모바일 디바이스(100)는 "networkQuality" 속성을 포함하고 속성 값을 계산된 처리량 값으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "networkQuality" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 내부 배터리의 순간 충전 레벨을 나타내는 미리정의된 속성(예를 들어, "system.batteryLevel")으로 구성될 수 있다. "batteryLevel" 속성은 배터리의 충전 레벨(예를 들어, 백분율)을 나타내는 값을 할당받을 수 있다. 예를 들어, 모바일 디바이스(100)는 배터리의 충전 레벨을 주기적으로(예를 들어, 5초마다, 1분마다, 15분마다 등으로) 결정하고, 배터리의 충전 레벨을 기록하기 위해 "batteryLevel" 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 배터리 충전 레벨을 모니터링하고, 충전 레벨이 임계량만큼 언제 변화하는지를 결정하고 배터리의 충전 레벨을 기록하기 위해 "batteryLevel "이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "batteryLevel" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 열 레벨(thermal level)을 나타내는 미리정의된 속성(예를 들어, "system.thermalLevel")으로 구성될 수 있다. 예를 들어, 모바일 디바이스(100)의 열 레벨은 모바일 디바이스의 현재 동작 온도(예를 들어, 섭씨 온도)일 수 있다. 모바일 디바이스(100)의 열 레벨은 온도 값들의 범위를 나타내는 레벨(예를 들어, 고, 중, 저, 정상, 비정상 등)일 수 있다. 예를 들어, 모바일 디바이스(100)는 모바일 디바이스(100)의 열 상태를 모니터링하기 위한 유틸리티 또는 기능으로 구성될 수 있다. 온도의 변화 또는 열 레벨의 변화를 검출하면, 모바일 디바이스(100)의 열 유틸리티는, "thermalLevel" 속성을 포함하고 속성 값을 동작 온도 또는 현재 열 레벨로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "thermalLevel" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 n초(예를 들어, 2밀리초, 3초 등)의 기간에 걸쳐 모바일 디바이스(100)의 에너지 사용량을 나타내는 미리정의된 속성(예를 들어, "system.energy")으로 구성될 수 있다. 예를 들어, 사용자가 모바일 디바이스(100)의 기능(예를 들어, 애플리케이션의 호출, 디스플레이의 조명, 데이터의 전송 등)을 호출할 때, 모바일 디바이스(100)는 그 기능이 실행되고 있는 기간에 걸쳐 에너지 사용량을 모니터링하여 각각의 활동 또는 기능이 얼마나 많은 에너지를 사용하는지를 추정할 수 있다. 이어서 모바일 디바이스(100)는 "energy" 속성을 포함하고 속성 값을 계산된 평균 에너지 사용량으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "energy" 이벤트를 제출할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 n초(예를 들어, 2밀리초, 3초 등)의 기간에 걸쳐 모바일 디바이스(100)의 네트워크 데이터 사용량을 나타내는 미리정의된 속성(예를 들어, "system.networkBytes")으로 구성될 수 있다. 예를 들어, 사용자가 모바일 디바이스(100)의 네트워크 연결을 통해 데이터의 전송을 요구하는 기능을 호출하거나 동작을 시작할 때, 모바일 디바이스(100)는 일정 기간에 걸쳐 네트워크 데이터 사용량을 모니터링하여 각각의 활동 또는 기능이 얼마나 많은 네트워크 데이터를 사용하거나 전송하는지를 추정할 수 있다. 이어서 모바일 디바이스(100)는 "networkBytes" 속성을 포함하고 속성 값을 계산된 평균 네트워크 데이터 사용량으로 설정하는 이벤트를 생성할 수 있다. 모바일 디바이스(100)는 이벤트 데이터 저장소(104)에 저장하기 위해 샘플링 데몬(102)에 "networkBytes" 이벤트를 제출할 수 있다.

다른 미리정의된 속성들은, 모바일 디바이스(100)가 자신의 배터리를 충전하고 있는지 여부를 나타내는 참/거짓(예를 들어, 1/0) 속성 값을 갖는 "system.chargingStatus" 속성, (예를 들어, batteryLevel에 비례하는, mAh 단위로) 현재의 배터리 충전을 나타내는 속성 값을 갖는 "system.batteryCapacity" 속성, 및 피어 디바이스들의 출현들을 추적하는 디바이스 식별자(예를 들어, 문자열) 속성 값을 갖는 "system.devicePresence" 속성을 포함할 수 있다. 예를 들어, "devicePresence" 속성은 피어-투-피어 데이터 공유를 스케줄링할 때 피어 디바이스들의 출현을 예측하는 데 사용될 수 있다.

커스텀 속성

일부 구현들에서, 클라이언트-특정 속성들은 샘플링 데몬(102)의 클라이언트들에 의해 동적으로 정의될 수 있다. 예를 들어, (예를 들어, 샘플링 데몬(102) 또는 운영 체제에서) 미리 정의되고 모바일 디바이스(100) 상에 구성된 속성들을 사용하는 대신에, 클라이언트들(예를 들어, 제3자 애플리케이션들)은 그들 자신의 이벤트 속성들을 동적으로 정의할 수 있다. 예를 들어, 이메일 애플리케이션은 동적으로(예를 들면, 런타임 시) "mailbox" 속성을 생성할 수 있다. 이메일 애플리케이션("mailapp")은 샘플링 데몬(102)의 API를 사용하여 속성 이름(예를 들어, "mailapp.mailbox") 및 속성 값 유형(예를 들어, 문자열, 정수, 부동)을 정의할 수 있다. 클라이언트가 새로운 커스텀 속성을 생성(등록)했으면, 클라이언트는 속성을 사용하여 이벤트 데이터 저장소(104)에 저장될 이벤트들을 생성할 수 있다. 예를 들어, 메일앱은 "mailbox" 속성을 사용하여, 이메일 애플리케이션에서 사용자가 어느 메일함에 액세스하고 있는지를 보고할 수 있다. 사용자가 "work" 메일함에 액세스하고 있는 경우, 메일앱은 "mailapp.mailbox" 속성을 사용하여 이벤트를 생성하고 속성의 값을 "work"로 설정하여 사용자가 "work" 메일함에 액세스하고 있음을 기록할 수 있다. 이어서 샘플링 데몬(102) 및 클라이언트는 저장된 메일함 이벤트 정보를 사용하여, 예를 들어, 사용자가 향후에 "work" 메일함에 언제 액세스할 가능성이 있는지를 예측할 수 있다.

일부 구현들에서, 클라이언트 애플리케이션이 모바일 디바이스(100)로부터 제거(예를 들어, 삭제, 설치해제)되는 경우, 클라이언트 애플리케이션에 의해 생성된 속성들은 모바일 디바이스(100)로부터 삭제될 수 있다. 또한, 클라이언트 애플리케이션이 제거되는 경우, 클라이언트 애플리케이션과 연관된 이벤트 데이터는 삭제될 수 있다. 예를 들어, 모바일 디바이스(100)로부터 메일앱이 삭제되는 경우, 속성 "mailapp.mailbox"는 메일앱과 연관된 모든 이벤트 데이터와 함께 모바일 디바이스(100)로부터 삭제될 수 있다.

예시적인 이벤트 생성 클라이언트

일부 구현들에서, 샘플링 데몬(102)은 애플리케이션 관리자 프로세스(106)로부터 애플리케이션 이벤트들(예를 들어, "system.bundleId" 이벤트들)을 수신할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 모바일 디바이스(100) 상에서 애플리케이션들(예를 들어, 애플리케이션(108))을 시작하고, 중지하고, 모니터링하는 프로세스일 수 있다. 일부 구현들에서, 애플리케이션 관리자(106)는 모바일 디바이스(100) 상에서 실행되는 애플리케이션들에 대한 시작 및 중지 횟수(예를 들어, "bundleId" 시작 및 중지 이벤트들)를 샘플링 데몬(102)에 보고할 수 있다. 예를 들면, 사용자가 애플리케이션을 호출하거나 개시하는 경우, 애플리케이션 관리자(106)는 애플리케이션의 이름 또는 식별자를 특정하는 호출된 애플리케이션에 대한 "bundleId" 시작 이벤트를 제출함으로써 애플리케이션 호출을 샘플링 데몬(102)에 통지할 수 있다. 일부 구현들에서, 애플리케이션 관리자(106)는 푸시 통지, 사용자 호출 또는 예상되거나 예측된 사용자 애플리케이션 호출에 응답하여 애플리케이션 개시가 시작되었음을 샘플링 데몬(102)에 나타낼 수 있다. 애플리케이션이 종료되는 경우, 애플리케이션 관리자(106)는 애플리케이션의 이름 또는 식별자를 특정하는 애플리케이션에 대한 "bundleId" 중지 이벤트를 제출함으로써 애플리케이션이 더 이상 실행되고 있지 않음을 샘플링 데몬(102)에 통지할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 애플리케이션 시작 및 종료 이벤트들(예를 들어, "bundleId" 속성 이벤트들)을 사용하여 애플리케이션 당 사용 횟수의 이력을 생성할 수 있다. 예를 들면, 애플리케이션 당 사용 횟수의 이력은, 애플리케이션의 각 실행에 대한, 애플리케이션의 최종 실행 이래로 경과한 시간의 양 및 실행 지속기간을 포함할 수 있다. 샘플링 데몬(102)은 사용자 호출된 애플리케이션 개시들 및/또는 시스템 개시된(예를 들어, 자동으로 개시된) 애플리케이션들의 별도의 이력을 유지할 수 있다. 따라서, 샘플링 데몬(102)은 모바일 디바이스(100) 상에서 실행되는 모든 애플리케이션들에 대한 사용 통계치를 유지할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 전력 모니터 프로세스(108)로부터 전력 이벤트들을 수신할 수 있다. 예를 들면, 전력 모니터(108)는 모바일 디바이스(100)에 대한 배터리 용량, 방전, 사용 및 충전 특성들을 모니터링할 수 있다. 전력 모니터(108)는 모바일 디바이스(100)가 언제 외부 전력원들에 플러그인되는지 그리고 모바일 디바이스(100)가 언제 배터리 전력을 공급받는지를 결정할 수 있다. 전력 모니터(108)는 모바일 디바이스(100)가 외부 전력에 플러그인될 때 샘플링 데몬(102)에 통지할 수 있다. 예를 들면, 전력 모니터(108)는, 모바일 디바이스(100)가 외부 전력원에 플러그인됨을 전력 모니터가 검출할 때, 1(예를 들어, 참)의 "cablePlugin" 속성 값을 갖는 "cablePlugin" 이벤트를 샘플링 데몬(102)에 송신할 수 있다. 이벤트는 외부 전력원이 연결되는 시간에서의 배터리 충전을 포함할 수 있다. 전력 모니터(108)는 배터리 사용량을 보고하기 위해 샘플링 데몬(102)에 "energy" 속성 이벤트들을 송신할 수 있다.

일부 구현들에서, 전력 모니터(108)는 모바일 디바이스(100)가 외부 전력으로부터 연결해제될 때 샘플링 데몬(102)에 통지할 수 있다. 예를 들면, 전력 모니터(108)는, 모바일 디바이스(100)가 외부 전력원으로부터 연결해제됨을 전력 모니터가 검출할 때, 0(예를 들어, 거짓)의 "cablePlugin" 속성 값을 갖는 "cablePlugin" 이벤트를 샘플링 데몬(102)에 송신할 수 있다. 메시지는 외부 전력원이 연결해제되는 시간에서의 배터리 충전을 포함할 수 있다. 따라서, 샘플링 데몬(102)은 모바일 디바이스(100)의 배터리들의 충전 분배(예를 들어, 시간에 따른 충전)를 설명하는 통계치를 유지할 수 있다. 충전 분배 통계치는 최종 충전 이래로의 시간의 양(예를 들면, 외부 전력에 플러그인된 이래로의 시간) 및 충전에 기인한 배터리 충전의 변화(예를 들면, 충전의 시작 레벨, 충전의 종료 레벨)를 포함할 수 있다.

일부 구현들에서, 전력 모니터(108)는 하루 종일의 배터리 충전의 변화들을 샘플링 데몬(102)에 통지할 수 있다. 예를 들면, 전력 모니터(108)는 애플리케이션들이 언제 시작하고 중지하는지를 통지받고, 통지들에 응답하여, 그 기간 동안 방전되는 배터리 전력의 양 및 배터리에 남은 충전의 양을 결정하며, 이 정보를 샘플링 데몬(102)에 전송할 수 있다. 예를 들어, 전력 모니터(108)는 애플리케이션이 활성 상태였던 기간에 걸쳐 소비된 에너지의 양을 나타내기 위해 샘플링 데몬(102)에 "system.energy" 이벤트를 송신할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 열 데몬(110)으로부터 디바이스 온도 통계치를 수신할 수 있다. 예를 들면, 열 데몬(110)은 하나 이상의 온도 센서를 사용하여 모바일 디바이스(100)의 동작 온도 상태들을 모니터링할 수 있다. 열 데몬(110)은 샘플링 데몬(102)에 온도 변화들을 주기적으로 보고하도록 구성될 수 있다. 예를 들면, 열 데몬(110)은 5초마다 모바일 디바이스(100)의 동작 온도를 결정하고 모바일 디바이스(100)의 온도 또는 열 레벨을 샘플링 데몬(102)에 보고할 수 있다. 예를 들어, 열 데몬(110)은 샘플링 데몬(102)에 "system.thermalLevel" 이벤트를 송신하여 모바일 디바이스(100)의 현재 동작 온도 또는 열 레벨을 보고할 수 있다. 샘플링 데몬(102)은 보고된 온도들을 이벤트 데이터 저장소(104)에 저장할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 디바이스 설정 프로세스(112)로부터 디바이스 설정 통계치를 수신할 수 있다. 예를 들면, 디바이스 설정 프로세스(112)는 모바일 디바이스(100)의 운영 체제의 기능 또는 프로세스일 수 있다. 디바이스 설정 프로세스(112)는 예를 들어, 사용자 입력을 수신하여, 에어플레인 모드 켜기/끄기, Wi-Fi 켜기/끄기, 로밍 켜기/끄기 등과 같은 다양한 디바이스 설정을 조정할 수 있다. 디바이스 설정 프로세스(112)는 디바이스 설정에 대한 변화들을 샘플링 데몬(102)에 보고할 수 있다. 각각의 디바이스 설정은 대응하는 미리정의된 이벤트 속성을 가질 수 있다. 예를 들면, 디바이스 설정 프로세스(112)는 사용자가 모바일 디바이스(100) 상에서 에어플레인 모드를 켜거나 끌 때 샘플링 데몬(102)에 "system.airplaneMode" 이벤트를 송신할 수 있다. 샘플링 데몬(102)은 수신된 이벤트들 및 속성 값들에 기초하여 디바이스 설정에 대한 통계치를 생성하고 저장할 수 있다. 예를 들면, 설정이 인에이블되는(또는 디스에이블되는) 각 시간에 대하여, 샘플링 데몬(102)은 설정이 이전에 인에이블된 이래로 경과한 시간의 양 및 설정이 인에이블되었던 시간의 양(예를 들어, 지속기간)을 나타내는 데이터를 저장할 수 있다.

유사하게, 일부 구현들에서, 샘플링 데몬(102)은 다른 이벤트들이 발생할 때 다른 모바일 디바이스(100) 컴포넌트들(예를 들어, 디바이스 센서들(114))로부터 통지들을 수신할 수 있다. 예를 들면, 샘플링 데몬(102)은, 모바일 디바이스의 스크린이 켜지거나 꺼질 때(예를 들어, "system.backlight" 이벤트), 모바일 디바이스(100)가 사용자의 얼굴 옆에서 유지될 때(예를 들어, "system.proximity" 이벤트), 셀 타워 핸드오프(cell tower handoff)가 검출될 때, 기저대역 프로세서가 검색 모드에 있을 때(예를 들어, "system.btlescan" 이벤트), 모바일 디바이스(100)가 사용자가 걷고 있고, 달리고 있고/있거나 운전하고 있음을 검출할 때(예를 들어, "system.motionState" 이벤트) 통지들을 수신할 수 있다. 각각의 경우에서, 샘플링 데몬(102)은 이벤트의 시작 및 종료 시에 통지를 수신할 수 있다. 각각의 경우에서, 샘플링 데몬(102)은 이벤트가 마지막으로 검출된 이래로 경과한 시간의 양 및 이벤트의 지속기간을 나타내는 통계치를 생성하고 저장할 수 있다. 샘플링 데몬(102)은 다른 이벤트 통지들을 수신하고 다른 통계치를 생성할 수 있고, 이는 특정 사용 경우들 및 시나리오들에 관하여 이하 더 설명되는 바와 같다.

애플리케이션 이벤트

일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(100) 상의 애플리케이션들로부터 이벤트 정보를 수신할 수 있다. 예를 들어, 모바일 디바이스(100) 상의 애플리케이션들은 미리정의된 또는 동적으로 정의된 속성들을 포함하는 이벤트들을 샘플링 데몬(102)에 생성하여 다양한 애플리케이션-특정 이벤트들을 추적할 수 있다. 예를 들어, 샘플링 데몬(102)은 캘린더 애플리케이션(116)으로부터 캘린더 이벤트들(예를 들어, "calendar.appointment", "calendar.meeting", 또는 "calendar.reminder" 속성 등을 포함함)을 수신할 수 있다. 캘린더 이벤트들은 위치들, 시간들, 또는 다양한 캘린더 이벤트들 또는 기능들과 연관된 다른 데이터를 특정하는 값들을 갖는 "calendar.appointment", "calendar.meeting", 또는 "calendar.reminder" 속성을 포함할 수 있다. 샘플링 데몬(102)은 예를 들어, 속성 이름, 속성 지속기간 및/또는 속성이 발생하도록 스케줄링된 시간을 저장할 수 있다. 일부 구현들에서, 샘플링 데몬(102)은 시계 애플리케이션(118)으로부터 시계 이벤트들(예를 들어, "clock.alarm" 속성을 포함함)을 수신할 수 있다. 예를 들어, 샘플링 데몬(102)은 속성 이름(예를 들어, "clock.alarm") 및 알람이 발생하도록 스케줄링된 시간을 나타내는 값을 저장할 수 있다. 샘플링 데몬(102)은 다른 애플리케이션들(예를 들어, 미디어 애플리케이션, 패스북(passbook) 애플리케이션 등)로부터 이벤트 정보를 수신할 수 있고, 이는 이하 더 설명되는 바와 같다.

애플리케이션 통계치

일부 구현들에서, 샘플링 데몬(102)은 애플리케이션 개시 이벤트들에 걸쳐 애플리케이션 통계치를 수집할 수 있다. 예를 들면, 샘플링 데몬(102)은 애플리케이션의 많은 호출들에 걸쳐 각 애플리케이션에 대한 통계치(예를 들어, 이벤트들, "bundleId" 속성 값들)를 수집할 수 있다. 예를 들면, 각 애플리케이션은 동일한 애플리케이션의 상이한 버전들이 별개의 애플리케이션들로서 취급될 수 있도록 자신의 실행파일(executable)의 파일시스템 경로의 해시(hash) 및 실행파일의 콘텐츠의 해시를 이용하여 식별될 수 있다. 애플리케이션 해시 값은 예를 들어, "bundleId" 이벤트에서 "bundleId" 속성에 대한 값으로서 샘플링 데몬(102)에 제출될 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 각 애플리케이션에 대한 백그라운드 태스크 완료 표명 이벤트들을 추적하는 카운터를 유지할 수 있다. 예를 들면, 애플리케이션이 백그라운드 태스크로서 실행될 때마다(예를 들어, 포그라운드(foreground)에서 볼 수 없고/없거나 사용자에 의해 현재 사용되고 있지 않음), 애플리케이션 또는 애플리케이션 관리자(106)는 애플리케이션이 종료되거나 보류될 때 샘플링 데몬(102)에 통지할 수 있고 샘플링 데몬(102)은 카운터를 증분시킬 수 있다. 샘플링 데몬(102)은 애플리케이션이 백그라운드에서 실행된 애플리케이션 개시들에 걸쳐 누적 초수를 추적하는 카운터를 유지할 수 있다. 예를 들어, 샘플링 데몬(102)은 "bundleId" 시작 및 중지 이벤트들을 분석하여 애플리케이션들이 언제 시작되고 중지되는지를 결정하고, 시작 및 중지 이벤트들의 타임스탬프들을 사용하여 애플리케이션이 얼마나 오랫동안 실행되었는지를 결정할 수 있다. 일부 구현들에서, 샘플링 데몬(102)은, 데이터 연결들의 개수를 카운트하고, 네트워크 데이터 트래픽의 양을 (예를 들어, 바이트들로) 추적하고, 파일시스템 동작들의 지속기간 및 크기를 추적하고/하거나 각 애플리케이션과 연관된 스레드(thread)들의 개수를 추적하는 별도의 카운터들을 유지할 수 있다. 샘플링 데몬(102)은 예를 들어, 애플리케이션 개시들에 걸쳐 애플리케이션이 활성 상태를 유지하는 누적 시간의 양의 카운트를 유지할 수 있다. 이들은 샘플링 데몬(102)에 의해 수신되고 이벤트 데이터 저장소(104)에 저장된 이벤트들 및 속성 데이터에 기초하여 샘플링 데몬(102)에 의해 생성될 수 있는 애플리케이션 통계치의 유형들의 단지 일부 예들이다. 다른 통계치가 이하 더 설명하는 바와 같이 생성되거나 수집될 수 있다.

휴리스틱

일부 구현들에서, 모바일 디바이스(100)는 샘플링 데몬(102)에 의해 검출된 이벤트들에 기초하여 디바이스 컴포넌트들의 설정을 조정할 수 있는 휴리스틱 프로세스들로 구성될 수 있다. 예를 들면, 휴리스틱 프로세스들(120)은 하나 이상의 트리거 이벤트에 응답하여 그리고/또는 샘플링 데몬(102)에 의해 수집되거나 생성된 통계치에 기초하여 다양한 시스템 설정(예를 들어, CPU 전력, 기저대역 프로세서 전력, 디스플레이 조명 등)을 조정하도록 구성되는(예를 들어, 프로그래밍되는) 하나 이상의 프로세스를 포함할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)는 미리정의된 세트의 기준들이 충족될 때(예를 들어, 소정 트리거 이벤트의 발생) 호출되거나 활성화되도록 샘플링 데몬(102)에 등록할 수 있다. 트리거 이벤트들은 미디어 플레이어 애플리케이션의 호출(예를 들어, "bundleId" 이벤트) 또는 사용자가 걷기, 달리기, 운전 등을 시작했음을 검출하는 것(예를 들어, "motionState" 이벤트)을 포함할 수 있다. 트리거 이벤트는 소정 특성, 데이터, 통계치, 이벤트, 속성, 속성 값 등이 이벤트 데이터(104)에서 또는 샘플링 데몬(102)에 의해 검출될 때 휴리스틱 프로세스(120)를 호출하도록 일반화될 수 있다. 예를 들면, 휴리스틱 프로세스(120)는 샘플링 데몬(102)이 애플리케이션 시작 통지(예를 들어, 특정 애플리케이션을 특정하는 "bundleId" 시작 이벤트) 또는 소정 임계값 초과의 온도(예를 들어, "thermalLevel" 이벤트)를 수신할 때 호출될 수 있다. 휴리스틱 프로세스(120)는 샘플링 데몬(102)이 특정된 속성 또는 속성 값과 연관된 이벤트를 수신할 때 호출될 수 있다. 휴리스틱 프로세스(120)는 단일 이벤트가 발생하거나 통계치가 관찰될 때 호출되도록 등록할 수 있다. 휴리스틱 프로세스(120)는 이벤트, 데이터, 속성, 속성 값 및/또는 통계치의 조합이 관찰되거나 검출될 때 호출되도록 등록할 수 있다. 휴리스틱 프로세스(120)는 특정 사용자 입력(예를 들어, "airplaneMode" 이벤트, "sleepWake" 이벤트 등)에 응답하여 트리거되거나 호출될 수 있다. 샘플링 프로세스(102)가 휴리스틱 프로세스(120)가 등록한 이벤트들을 검출하는 경우, 샘플링 프로세스(102)는 휴리스틱 프로세스(120)를 호출할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)가 호출되는 경우, 휴리스틱 프로세스(120)는 샘플링 데몬(102)과 통신하여 이벤트 데이터 저장소(104)로부터 이벤트 데이터를 검색할 수 있다. 휴리스틱 프로세스(120)는, 이벤트 데이터, 및/또는 모바일 디바이스(100)의 성능을 향상시키기 위하여, 모바일 디바이스(100)를 사용하는 동안 사용자의 경험을 향상시키기 위하여, 그리고/또는 모바일 디바이스(100)가 갖는 향후 문제점을 방지하기 위하여 시스템 설정을 어떻게 조정할지를 결정하도록 휴리스틱 프로세스(120)가 자체적으로 수집하는 다른 데이터를 처리할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)는 모바일 디바이스(100)의 다양한 디바이스 컴포넌트들(122)의 설정의 변화를 야기할 수 있는 설정 추천들을 할 수 있다. 예를 들면, 디바이스 컴포넌트들은 CPU, GPU, 기저대역 프로세서, 디스플레이, GPS, 블루투스, Wi-Fi, 진동 모터 및 다른 컴포넌트들을 포함할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)는 제어 멀티플렉서(124)에 설정 추천들을 할 수 있다. 예를 들면, 제어 멀티플렉서(124)는 휴리스틱 프로세스들(120)에 의해 제공된 컴포넌트 설정들 사이에서 중재하는 프로세스, 및 모바일 디바이스(100)의 컴포넌트들의 설정에 영향을 주거나 그것들을 변경하는 모바일 디바이스(100)의 다른 프로세스들 및/또는 기능들일 수 있다. 예를 들면, 열 데몬(110)은 모바일 디바이스(100)가 열 이벤트(예를 들어, 임계 온도 초과) 중에 있음을 검출하는 것에 기초하여, CPU 전력, 디스플레이 밝기, 기저대역 프로세서 전력 및 다른 컴포넌트 설정들을 조정하도록 구성되는 휴리스틱 프로세스일 수 있다. 그러나, 휴리스틱 프로세스(120)는 CPU 전력, 디스플레이 밝기, 기저대역 프로세서 전력 및 다른 컴포넌트 설정들도 조정하도록 구성될 수 있다. 따라서, 일부 구현들에서, 휴리스틱 프로세스(120) 및 열 데몬(110)은 제어 멀티플렉서(124)에 설정 조정 추천들을 할 수 있고, 제어 멀티플렉서(124)는 어떤 설정 조정들을 행할지를 결정할 수 있다. 예를 들면, 제어 멀티플렉서(124)는 프로세스들의 우선순위를 정하고 추천 프로세스의 우선순위에 기초하여 조정들을 수행할 수 있다. 따라서, 열 데몬(110)이 휴리스틱 프로세스(120)보다 더 높은 우선순위 프로세스인 경우, 제어 멀티플렉서(124)는 휴리스틱 프로세스(120) 대신에 열 데몬(110)의 추천들에 따라 CPU, 디스플레이, 기저대역 프로세서 등의 설정을 조정할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 다수의 휴리스틱 프로세스들(120)로 구성될 수 있다. 휴리스틱 프로세스들(120)은 무선으로(over the air) 구성되거나 재구성될 수 있다. 예를 들면, 각 휴리스틱 프로세스(120)의 파라미터들(예를 들어, 트리거, 임계값, 기준, 및 출력)은 네트워크(예를 들어, 셀룰러 데이터 연결, Wi-Fi 연결 등)를 통해 설정되거나 조정될 수 있다. 일부 구현들에서, 신규 휴리스틱 프로세스들(120)이 모바일 디바이스(100)에 추가될 수 있다. 예를 들면, 트리거 이벤트들, 통계 데이터 및 디바이스 설정들 사이의 시간에 따른 신규 상관관계들이 시스템 개발자들에 의해 결정될 수 있다. 이러한 신규 상관관계들이 식별됨에 따라, 신규 휴리스틱 프로세스들(120)은 새로 결정된 관계들을 설명하기 위해 시스템 설정을 조정하도록 개발될 수 있다. 일부 구현들에서, 신규 휴리스틱 프로세스들(120)은 네트워크를 통해 모바일 디바이스(100)에 추가될 수 있다. 예를 들면, 신규 휴리스틱 프로세스들(120)은 무선으로(예를 들어, 셀룰러 데이터 연결, Wi-Fi 연결 등) 모바일 디바이스(100) 상에 다운로드되거나 설치될 수 있다.

예시적인 휴리스틱 프로세스

일부 구현들에서, 휴리스틱 프로세스(120)는 모바일 디바이스(100)의 시스템 설정을 조정하여 모바일 디바이스(100)가 사용자의 주머니 안에 있을 때 너무 뜨거워지는 것을 방지하도록 구성될 수 있다. 예를 들면, 이러한 핫-인-포켓(hot-in-pocket) 휴리스틱 프로세스는, 모바일 디바이스의 디스플레이가 꺼져있을 때(예를 들어, "system.backlight" 이벤트가 0/거짓의 속성 값을 가짐) 그리고 모바일 디바이스(100)가 어떠한 엔터테인먼트 미디어(예를 들어, 음악, 영화, 비디오 등)도 재생하고 있지 않을 때 호출되도록 샘플링 데몬(102)에 등록하도록 구성될 수 있다. 호출될 때, 핫-인-포켓 휴리스틱은 예를 들면, CPU 전력 및 GPU 전력을 감소시켜 모바일 디바이스(100)의 동작 온도를 감소시키기 위한 추천들을 할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)는 모바일 디바이스의 디스플레이가 사용되고 있지 않을 때(예를 들어, "system.backlight" 이벤트가 0/거짓의 속성 값을 가짐) 위치 정확도를 조정하도록 구성될 수 있다. 예를 들면, 모바일 디바이스의 디스플레이가 사용되고 있지 않은 경우(예를 들어, 전술한 "backlight" 속성 이벤트에 의해 나타낸 바와 같이, 디스플레이가 꺼짐), 모바일 디바이스(100)는 사용자에게 맵 정보 또는 길 안내를 표시할 수 없다. 따라서, 사용자는 모바일 디바이스(100)의 위치 서비스들을 사용할 가능성이 없고, 위치 서비스들(예를 들어, GPS 위치, Wi-Fi 위치, 셀룰러 위치 등)은 더 적은 전력을 사용하도록 조정될 수 있다. 위치 정확도 휴리스틱 프로세스는 모바일 디바이스의 디스플레이가 꺼져 있을 때 호출되도록 샘플링 데몬(102)에 등록할 수 있다. 호출될 때, 휴리스틱 프로세스는 모바일 디바이스(100)의 에너지 리소스들을 보존하기 위해 GPS 프로세서, Wi-Fi 송신기, 셀룰러 송신기, 기저대역 프로세서의 전력 레벨들을 조정하거나 모바일 디바이스(100)의 위치를 결정하는 데 사용되는 프로세스들을 종료할 수 있다.

일부 구현들에서, 휴리스틱 프로세스(120)는 사용자의 행동에 응답하여 모바일 디바이스의 주변광 센서의 설정을 조정하도록 구성될 수 있다. 예를 들면, 이러한 사용자-적응(user-adaptive) 주변광 센서(ALS) 휴리스틱 프로세스는, 주변광 센서가 모바일 디바이스(100)를 둘러싸는 주변광의 변화를 검출했음을, 주변광 센서 시스템이 디스플레이의 밝기를 조정했음을, 그리고/또는 사용자가 디스플레이의 밝기를 조정하기 위한 입력을 제공했음을 나타내는 데이터(예를 들어, "ALS" 속성 이벤트)를 샘플링 데몬(102)이 수신할 때, 샘플링 데몬(102)에 의해 호출될 수 있다.

호출될 때, 사용자-적응 ALS 휴리스틱은, ALS 디스플레이 조정들 및 사용자 시작된 디스플레이 조정들에 관하여 샘플링 데몬(102)으로부터 추가 정보를 요청하여, ALS가 디스플레이 밝기를 올리거나 내리도록 조정하고 사용자가 반대 방향으로 디스플레이 밝기를 조정하는 때를 나타내는 사용자 입력의 패턴이 있는지를 결정할 수 있다(예를 들어, "system.ALS" 이벤트에 뒤이은 "system.backlight" 이벤트). 예를 들면, 사용자는 직장까지 버스나 기차를 탈 수 있다. 타고 있는 동안 버스 조명은 켜지고 꺼질 수 있다. 주변광 센서는 주변광의 변화를 검출하고, 조명이 켜지는 경우 디스플레이 밝기를 증가시킬 수 있다. 조명은 일시적으로만 켜지므로, 사용자는 조명이 다시 꺼지는 경우 디스플레이 밝기를 감소시킬 수 있다. 사용자 입력의 이러한 패턴은, ALS 디스플레이 조정에 응답하여 어떠한 환경 또는 콘텍스트 하에서 사용자가 디스플레이 밝기를 조정하는지를 결정하기 위해, 휴리스틱 프로세스에 의해 하루 중 시간, 캘린더나 알람 이벤트 엔트리, 또는 이동 패턴에 상관되거나 (예를 들어, "backlight" 속성 이벤트들 통해) 추적될 수 있다. 사용자-적응 ALS 휴리스틱 프로세스가 입력의 패턴 및 콘텍스트를 결정하면, 휴리스틱 프로세스는 ALS의 설정을 더 또는 덜 적극적이 되도록 조정할 수 있다. 예를 들면, ALS는 하루 중 결정된 시간 동안 더 또는 덜 자주 주변광의 레벨, 캘린더나 알람 엔트리, 또는 이동 패턴을 체크하도록 조정되고 이에 따라 디스플레이 밝기를 조정할 수 있다.

상기 휴리스틱 프로세스들은 휴리스틱 프로세스들 및 본 명세서에 설명된 시스템에서 그것들이 어떻게 구현될 수 있는지의 몇 가지 예들이다. 다른 휴리스틱 프로세스들이 구현될 수 있고 시간이 지남에 따라 개발될 때 시스템에 추가될 수 있다. 예를 들면, 추가 휴리스틱 프로세스들은, 온도 측정, 사용자 입력, 시계 이벤트(예를 들어, 알람), 캘린더 이벤트 및/또는 모바일 디바이스 상에서 발생하고 검출되는 다른 이벤트들에 관련된 이벤트들 또는 이벤트들의 패턴들을 검출하는 것에 응답하여, CPU, GPU, 기저대역 프로세서들, 또는 모바일 디바이스의 다른 컴포넌트들을 조정하도록 구성되거나 프로그래밍될 수 있다.

예시적인 휴리스틱 등록 및 호출 프로세스

도 2는 휴리스틱 프로세스들을 호출하기 위한 예시적인 프로세스(200)를 예시한다. 단계(202)에서, 샘플링 데몬(102)이 초기화될 수 있다. 예를 들면, 샘플링 데몬(102)은 모바일 디바이스(100)의 시동 동안 초기화될 수 있다.

단계(204)에서, 샘플링 데몬(102)은 샘플링 데몬(102)의 초기화 동안 모바일 디바이스(100) 상에 구성된 휴리스틱 프로세스들을 호출할 수 있다. 예를 들면, 샘플링 데몬(102)은 각 휴리스틱 프로세스(120)로 하여금 모바일 디바이스(100) 상에서 실행되고 그것들의 초기화 서브루틴(initialization subroutine)들을 통해 실행되게 할 수 있다.

단계(206)에서, 샘플링 데몬(102)은 각 휴리스틱 프로세스(120)로부터 이벤트 등록 메시지들을 수신할 수 있다. 예를 들면, 휴리스틱 프로세스들(120)의 초기화 서브루틴들 동안, 휴리스틱 프로세스들(120)은 어느 속성 이벤트들이 휴리스틱 프로세스(120)의 호출을 트리거해야 하는 것인지를 나타내는 정보를 샘플링 데몬(102)에 송신할 수 있다. 샘플링 데몬(102)은 등록 정보를, 예를 들어, 이벤트 데이터 저장소(104)와 같은 데이터베이스에 저장할 수 있다. 등록 정보는, 특정된 이벤트가 검출될 때 샘플링 데몬(102)이 휴리스틱 프로세스(120)를 호출할 수 있도록, 휴리스틱 프로세스의 식별(예를 들어, 실행파일 이름, 파일 시스템 경로 등) 및 이벤트 기준들(속성, 속성 값, 임계치, 범위 등의 식별)을 포함할 수 있다.

단계(208)에서, 샘플링 데몬(102)은 속성 이벤트 데이터를 수신할 수 있다. 예를 들면, 샘플링 데몬(102)은, 전술한 바와 같이, 애플리케이션 관리자(106), 센서들(114), 캘린더(116) 및 시계(118)를 포함하는 다양한 시스템 컴포넌트들로부터 속성 이벤트 데이터를 수신할 수 있다.

단계(210)에서, 샘플링 데몬(102)은 수신된 속성 이벤트 데이터를 휴리스틱 등록 데이터와 비교할 수 있다. 예를 들면, 속성 이벤트 데이터가 샘플링 데몬(102)에 보고됨에 따라, 샘플링 데몬(102)은 이벤트 데이터(예를 들어, 속성 값들), 또는 이벤트 데이터로부터 생성된 통계치를, 휴리스틱 프로세스(120)로부터 수신된 등록 정보와 비교할 수 있다.

단계(212)에서, 샘플링 데몬(102)은 단계(210)에서 수행된 비교에 기초하여 휴리스틱 프로세스를 호출할 수 있다. 예를 들면, 이벤트 데이터(예를 들어, 속성 데이터) 및/또는 통계치가 휴리스틱 프로세스(120)에 대한 휴리스틱 등록 데이터에서 특정된 기준을 충족하는 경우, 샘플링 데몬(102)은 휴리스틱 프로세스(120)를 호출할 수 있다. 예를 들면, 이벤트 데이터 및/또는 통계 데이터가 등록 동안 휴리스틱 프로세스에 의해 이벤트에 대해 특정된 소정 임계값을 가로지르는 경우, 휴리스틱 프로세스는 샘플링 데몬(102)에 의해 호출될 수 있다. 대안적으로, 특정 속성 이벤트의 단순한 발생은 휴리스틱 프로세스(120)를 호출을 야기할 수 있다.

도 3은 휴리스틱 프로세스(120)를 사용하여 모바일 디바이스(100)의 설정을 조정하기 위한 프로세스(300)를 예시한다. 단계(302)에서, 휴리스틱 프로세스(120)가 초기화된다. 예를 들면, 휴리스틱 프로세스(120)는, 휴리스틱 프로세스(120)가 자신의 초기화 서브루틴들을 통해 실행될 수 있도록 샘플링 데몬(102)에 의해 호출될 수 있다. 예를 들면, 호출은 휴리스틱 프로세스(120)가 이러한 호출 동안 자신의 초기화 서브루틴들을 통해 실행되어야 함을 나타내도록 파라미터화될 수 있다.

단계(304)에서, 휴리스틱 프로세스(120)는 시스템 이벤트들에 대해 샘플링 데몬(102)에 등록할 수 있다. 예를 들면, 초기화 동안, 휴리스틱 프로세스(120)는 이벤트들, 임계치들, 속성들, 속성 값들 또는 휴리스틱 프로세스(120)를 호출하기 위한 다른 기준들의 식별을 포함하는 메시지를 샘플링 데몬(102)에 송신할 수 있다. 이벤트가 발생하고/하거나 기준들이 충족되는 경우, 샘플링 데몬(102)은 휴리스틱 프로세스(120)를 호출할 수 있다.

단계(306)에서, 휴리스틱 프로세스(120)는 셧다운되거나 종료될 수 있다. 예를 들면, 휴리스틱 프로세스(120)는 등록 기준들이 휴리스틱 프로세스(120)에 대해 충족될 때까지 시스템에 의해 필요하지 않다. 따라서, 디바이스 리소스들(예를 들어, 배터리 전력, 처리 전력 등)을 보존하기 위하여, 휴리스틱 프로세스(120)는 그것이 필요해질(예를 들어, 샘플링 데몬(102)에 의해 트리거될) 때까지 종료되거나, 셧다운되거나 또는 보류된다.

단계(308)에서, 휴리스틱 프로세스(120)는 재시작될 수 있다. 예를 들면, 샘플링 데몬(102)은, 등록 메시지에서 휴리스틱 프로세스(120)에 의해 특정된 기준들이 충족되었음을 샘플링 데몬(102)이 결정할 때, 휴리스틱 프로세스(120)를 호출할 수 있다.

단계(310)에서, 휴리스틱 프로세스(120)는 샘플링 데몬(102)으로부터 이벤트 데이터를 획득할 수 있다. 예를 들어, 재시작되면, 휴리스틱 프로세스(120)는 추가 속성 이벤트 데이터에 대해 샘플링 데몬(102)에 질의할 수 있다. 휴리스틱 프로세스(120)는 다른 시스템 리소스, 프로세스, 센서 등과 상호작용하여, 필요에 따라 데이터를 수집하도록 구성될 수 있다.

단계(312)에서, 휴리스틱 프로세스(120)는 이벤트 데이터를 처리하여 컴포넌트 설정을 결정할 수 있다. 예를 들면, 휴리스틱 프로세스(120)는 샘플링 데몬(102)으로부터의 이벤트 데이터 및/또는 통계치 및/또는 시스템의 다른 컴포넌트들로부터 수집된 데이터를 사용하여 모바일 디바이스(100)의 다양한 컴포넌트들의 설정을 어떻게 조정하는지를 결정할 수 있다. 예를 들어, 휴리스틱 프로세스(120)가 모바일 디바이스(100)가 너무 뜨겁다고 결정하는 경우, 휴리스틱 프로세스(120)는 모바일 디바이스(100)의 어떤 전력 설정이 모바일 디바이스(100)의 동작 온도를 감소시킬 것인지를 결정할 수 있다.

단계(314)에서, 휴리스틱 프로세스(120)는 결정된 컴포넌트 설정을 제어 멀티플렉서(124)에 전송할 수 있다. 예를 들면, 제어 멀티플렉서(124)는 휴리스틱 프로세스(120) 및 다른 시스템 컴포넌트들(예를 들어, 열 데몬(110))로부터 수신된 디바이스 설정 추천들을 중재할 수 있다. 이어서, 제어 멀티플렉서(124)는 수신된 설정 추천들에 따라 모바일 디바이스(100)의 다양한 컴포넌트들(예를 들어, CPU, GPU, 기저대역 프로세서, 디스플레이 등)을 조정할 수 있다.

이벤트를 예측

일부 구현들에서, 이벤트 데이터 저장소(104)에 저장된 속성 이벤트 데이터(예를 들어, 이력 데이터)는 향후 이벤트들의 발생을 예측하기 위해 샘플링 데몬(102)에 의해 사용될 수 있다. 예를 들어, "bundleId" 속성 이벤트들이 분석되어, 사용자가 애플리케이션들(예를 들어, 임의의 애플리케이션 또는 특정 애플리케이션)을 언제 호출할 것인지를 예측할 수 있다. 특정 이메일 폴더(예를 들어, "work" 폴더로 설정된 "mailbox" 속성 값)를 특정하는 "mailapp.mailbox" 이벤트가 분석되어, 사용자가 "mailapp" 애플리케이션의 특정 이메일 폴더를 언제 사용할 것인지를 예측할 수 있다.

이벤트 이력 윈도우 스펙(Event History Window Specification)

일부 구현들에서, 이벤트 예측은 이벤트 이력 윈도우 스펙에 기초하여 생성될 수 있다. 예를 들어, 윈도우 스펙은, 클라이언트가 이벤트 예측의 기초로 원하는 관심 기간, 또는 관심 반복 기간을 특정하기 위해 클라이언트에 의해 생성될 수 있다. 윈도우 스펙은 시작 시간, 종료 시간, 반복 폭, 및 반복 빈도의 4개 구성요소를 포함할 수 있다. 시작 시간은 윈도우가 시작되어야 할 때의 날짜 및/또는 시간을 이력에서 나타낼 수 있다. 종료 시간은 윈도우가 종료되어야 할 때의 날짜 및/또는 시간을 이력에서 나타낼 수 있다. 반복 폭은 클라이언트의 관심 대상인 시간의 블록(예를 들어, 시작 시간에서 시작하는 4시간)을 나타낼 수 있다. 반복 빈도는 시작 시간에서 시작하여 시간의 블록이 얼마나 자주 반복되어야 하는지를(예를 들어, 8시간마다, 2일마다, 매주, 2주마다 등) 나타낼 수 있다.

일부 구현들에서, 이벤트 예측을 생성할 때, 특정된 시간 블록(예를 들어, 관심 기간) 내에 발생하는 이벤트들만이 분석될 것이다. 예를 들어, 현재 날짜가 2014년 5월 13일인 경우, 윈도우 스펙은 2014년 5월 11일 오후 12:00의 시작 날짜, 5월 12일 오후 12시의 종료 날짜, 1시간의 반복 폭, 및 4시간의 반복 빈도를 특정할 수 있다. 이 윈도우 스펙은, 샘플링 데몬(102)으로 하여금 2014년 5월 11일 오후 12:00에 시작하여 2014년 5월 12일 오후 12:00에 종료하는 4시간마다 발생하는 각각의 1시간 블록(예를 들어, 관심 기간) 내의 이벤트 데이터를 분석하게 할 것이다(예를 들어, 블록 1: 2014년 5월 11일 오후 12:00-1:00; 블록 2: 2014년 5월 11일 오후 4:00-5:00; 블록 3: 2014년 5월 11일 오후 8:00-9:00 등). 일부 구현들에서, 반복 폭이 특정되지 않으면, 시작 시간에서 종료 시간까지의 전체 기간이 이벤트들을 예측하기 위해 분석될 것이다.

일부 구현들에서, 샘플링 데몬(102)은 이벤트 이력 윈도우 스펙을 자동으로 생성할 수 있다. 예를 들어, 샘플링 데몬(102)은 이벤트 데이터 저장소(104)에 저장된 이벤트 이력 데이터에서 패턴들을 식별할 수 있다. 클라이언트가 "bundleId" 이벤트들에 대한 예측을 요청하지만 윈도우 스펙을 제공하지 않는 경우, 샘플링 데몬(102)은 예를 들어, 애플리케이션들이 일반적으로 오전 8:00-9:00, 오전 11:30-오후 1:30, 그리고 오후 7:00-11:00에 사용자에 의해 호출됨을 나타내는, "bundleId" 속성/이벤트에 대한 패턴을 식별할 수 있다. 샘플링 데몬(102)은, 요청된 예측이 요청된 속성과 관련되는 기간들에 초점을 맞추도록, 그 기간들을 포함하고 하루 중 다른 시간들을 제외하는 윈도우 스펙을 자동으로 생성할 수 있다. 유사하게, 샘플링 데몬(102)은 특정(예를 들어, 특정된) 속성 값에 대한 이벤트 이력 윈도우 스펙을 자동으로 생성할 수 있다. 예를 들어, 클라이언트가 "mailapp"의 속성 값을 갖는 "bundleId" 이벤트들에 대한 예측을 요청하는 경우, 샘플링 데몬(102)은 이벤트 이력 데이터를 분석하여 "mailapp" 값에 관련된 발생들의 패턴들을 식별할 수 있다. "mailapp" "bundleId" 속성 값이 매일 오전 10:00, 오후 12:00 그리고 오후 5:00에 이벤트 이력 데이터에 기록되는 경우, 샘플링 데몬(102)은 하루 중 그 시간들 주변의 관심 기간들을 특정하는 윈도우 스펙을 생성할 수 있다.

시간 예측

일부 구현들에서, 속성 또는 속성 값에 대해 시간 예측이 생성될 수 있다. 시간 예측은 예를 들어, 속성 또는 속성 값과 연관된 이벤트가 하루 중 어떤 시간에 발생할 가능성이 있는지를 나타낼 수 있다. 예를 들어, 샘플링 데몬(102)의 클라이언트는 지난 주(예를 들어, 지난 7일)에 걸쳐 "bundleId" 속성(예를 들어, 애플리케이션 개시들)에 대한 시간 예측을 요청할 수 있다. 예측을 생성하기 위해, 24시간 하루가 96개의 15분 타임슬롯들로 분할될 수 있다. 지난 7일 각각에서 특정 타임슬롯(예를 들어, 오후 1:00-1:15)에 대해, 샘플링 데몬(102)은 "bundleId" 이벤트가 발생했는지를 결정하고 타임슬롯에 대한 점수를 생성할 수 있다. "bundleId" 이벤트가 7일 중 2일에서 특정 타임슬롯 동안 발생했으면, 특정 타임슬롯 동안(예를 들어, 오후 1:00-1:15) "bundleId" 이벤트가 발생할 가능성(예를 들어, 점수)은 0.29(예를 들어, 2를 7로 나눈 값)이다. "bundleId" 이벤트가 7일 중 4일에서 다른 타임슬롯(예를 들어, 오후 12:15-12:30) 동안 발생했으면, 그 타임슬롯 동안 "bundleId" 이벤트가 발생할 가능성(예를 들어, 점수)은 0.57(예를 들어, 4를 7로 나눈 값)이다.

유사하게, 클라이언트는 특정 속성 값에 대한 시간 예측을 요청할 수 있다. 예를 들어, "bundleId" 속성(예를 들어, "bundleId" 이벤트)에 대한 시간 예측을 요청하는 대신에, 클라이언트는 "bundleId" 속성 값이 "mailapp"인 "bundleId" 이벤트에 대한 시간 예측을 요청할 수 있다. 따라서, 클라이언트는, 사용자가 하루 중 어떤 시간(예를 들어, 15분 타임슬롯)에 "mailapp" 애플리케이션을 호출할 가능성이 있을 것인지에 대한 표시를 수신할 수 있다.

일부 구현들에서, 시간 예측은 이벤트 이력 윈도우 스펙에 기초하여 생성될 수 있다. 예를 들어, 클라이언트가 4시간의 관심 기간을 특정하는 윈도우 스펙을 제공하는 경우, 시간 예측은 4시간의 관심 기간 내에 있는 15분 타임슬롯들에 대한 가능성 점수들만을 생성할 것이다. 예를 들어, 관심 기간이 지난 3일 각각 동안 오후 12:00-4:00에 대응하는 경우, 4시간의 관심 기간 동안 16개의 타임슬롯들이 생성될 것이고 16개의 15분 타임슬롯들 각각에 대해 점수가 생성될 것이다. 특정된 4시간의 관심 기간 이외의 타임슬롯들에 대해서는 점수들이 생성되지 않을 것이다.

피어 예측

일부 구현들에서, 샘플링 데몬(102)은 속성들에 대한 피어 예측들을 생성할 수 있다. 예를 들어, 피어 예측은 관심 기간 동안 발생하는 속성에 대한 값들의 상대적 가능성들을, 동일한 속성의 모든 값들(예를 들어, 발생들)에 대해 나타낼 수 있다. 예를 들어, 샘플링 데몬(102)의 클라이언트는 요청과 함께 제출된 윈도우 스펙에 의해 특정된 관심 기간(예를 들어, 오전 11:00 ― 오후 1:00)에 걸쳐 "bundleId" 속성의 피어 예측을 요청할 수 있다. 관심 기간 동안, 속성 값들 "mailapp", "contacts", "calendar", "webbrowser", "mailapp", "webbrowser", "mailapp"을 갖는 "bundleId" 이벤트들이 발생하면, "mailapp"이 발생하는 상대적 가능성(즉, 점수)은 0.43(예를 들어, 3/7)이고, "webbrowser"가 발생하는 상대적 가능성은 0.29(예를 들어, 2/7)이며, "contacts" 또는 "calendar"가 발생하는 상대적 가능성들은 0.14(예를 들어, 1/7)이다.

일부 구현들에서, 샘플링 데몬(102)의 클라이언트는 속성에 대한 피어 예측을 요청할 수 있다. 예를 들어, 클라이언트가 속성에 대한 값을 특정하지 않고 속성에 대한 피어 예측을 요청하면, 샘플링 데몬(102)은 피어 예측을 생성하고, 관심 기간 내의 속성의 모든 값들에 대한 다양한 확률 점수들을 반환할 것이다. 위의 예시적인 피어 예측을 사용하면, 샘플링 데몬(102)은 속성 값들 및 점수들의 리스트를 요청 클라이언트에 반환할 것이며, 그 예는 다음과 같을 것이다: "mailapp": 0.43; "webbrowser": 0.29; "contacts": 0.14; "calendar": 0.14.

일부 구현들에서, 샘플링 데몬(102)의 클라이언트는 속성 값에 대한 피어 예측을 요청할 수 있다. 예를 들어, 클라이언트는 "mailapp"의 값을 갖는 "bundleId" 속성에 대한 피어 예측을 요청할 수 있다. 샘플링 데몬(102)은 전술한 바와 같이, 클라이언트에 의해 제공된 윈도우 스펙에 따라 "bundleId" 속성에 대한 피어 예측을 생성할 수 있다. 예를 들어, 샘플링 데몬(102)은, "mailapp"이 발생하는 상대적 가능성(즉, 점수)이 0.43(예를 들어, 3/7)이고, "webbrowser"가 발생하는 상대적 가능성은 0.29(예를 들어, 2/7)이며, "contacts" 또는 "calendar"가 발생하는 상대적 가능성들은 0.14(예를 들어, 1/7)인 것을 계산할 수 있다. 샘플링 데몬(102)은 요청된 "mailapp" 값에 대한 점수(예를 들어, 0.43)를 클라이언트에 반환할 수 있다. 요청된 값이 윈도우 스펙에 의해 특정된 관심 기간 내에 나타나지 않으면, 0의 값이 클라이언트에 반환될 것이다.

파노라마 예측

일부 구현들에서, 파노라마 예측은 속성 이벤트의 발생을 예측하기 위해 생성될 수 있다. 예를 들어, 전술한 시간 및 피어 예측들은 단일 속성 또는 속성 값에 대한 이벤트들의 발생의 상대적 빈도를 사용하여 그 속성의 향후 발생들을 예측한다. 이 "frequency" 예측 유형(예를 들어, 발생의 빈도)은 예측 요청에 특정된 속성 또는 속성 값과 연관된 데이터만을 사용한다. 반면에, "panorama" 예측은 예측 요청에 특정된 속성 또는 속성 값에 대한 수신된 이벤트 데이터 내의 다른 데이터(예를 들어, 위치 데이터, 비콘 데이터, 네트워크 품질 등)를 사용할 수 있다. 일부 구현들에서, 파노라마 예측은 다른 속성들 또는 속성 값들과 연관된 이벤트들로부터의 데이터를 사용할 수 있다. 예를 들어, 클라이언트가 특정된 속성 또는 속성 값에 대한 시간 예측 또는 피어 예측을 요청하고 또한 예측 유형(즉, 예측 특징(flavor))이 파노라마임을 특정하는 경우, 샘플링 데몬(102)은 특정된 속성 또는 속성 값에 대한 이벤트 데이터 및 다른 속성들 및 속성 값에 대한 이벤트 데이터를 분석하여, 특정된 이벤트와 샘플링 데몬(102)에 의해 수신된 다른 이벤트들 사이의 상관관계들을 식별할 것이다. 예를 들어, 값 "mailapp"을 갖는 속성 "bundleId"에 대한 빈도 예측은 오전 9:00의 15분 타임슬롯에 0.4의 점수를 할당할 수 있다. 그러나, 파노라마 예측은 "mailapp" 속성 값과 사용자의 직장 위치 사이에 강한 상관관계가 있음을 결정할 수 있다. 예를 들어, 파노라마 예측은, 사용자가 직장과 연관된 위치에 있으면, 메일앱이 오전 9:00의 15분 타임슬롯 내의 시간의 90%로 호출된다는 것을 결정할 수 있다. 따라서, 샘플링 데몬(102)은 오전 9:00의 15분 타임슬롯에 대한 "mailapp" 예측 점수에 더 높은 점수(예를 들어, 0.9)를 할당할 수 있다.

유사하게, 샘플링 데몬(102)은, "mailapp" "bundleId" 속성 값과, "motionState" 속성 값 "stationary"와 연관된 이벤트의 발생 사이에서 강한 상관관계를 발견할 수 있다. 예를 들어, 샘플링 데몬(102)은 메일앱 애플리케이션의 사용과 정지 상태인 모바일 디바이스(100) 사이의 상관관계가 95%임을 결정할 수 있다. 샘플링 데몬(102)은 메일앱의 사용과 이동 중인 모바일 디바이스(100) 사이의 상관관계가 5%임을 결정할 수 있다. 따라서, 샘플링 데몬(102)은 모바일 디바이스가 이동 중인지 정지 상태인지에 기초하여 특정 타임슬롯에 대한 "mailapp" 속성 값에 대한 예측 점수(예를 들어, 0.95 또는 0.05)를 조정할 수 있다.

스코어보드 - 빈도 대 파노라마

일부 구현들에서, 샘플링 데몬(102)은 어느 예측 유형이 이벤트들의 더 나은 예측자인지를 추적할 수 있다. 예를 들어, 샘플링 데몬(102)이 속성 이벤트를 수신하는 경우, 샘플링 데몬(102)은 수신된 이벤트와 연관된 속성 또는 속성 값에 대한 빈도 및 파노라마 예측들을 생성할 수 있고, 어느 예측 유형이 수신된 속성 이벤트의 더 나은 예측자였을지를 결정할 수 있다. 다르게 말하면, 샘플링 데몬(102)은, 속성 이벤트가 수신되기 직전에 예측들이 생성되었다면 빈도 예측 유형 또는 파노라마 예측 유형이 수신된 속성 이벤트의 더 나은 예측자였을지를 결정할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 각각의 예측 유형(예를 들어, 디폴트, 파노라마)에 대한 스코어보드를 유지할 수 있다. 예를 들어, 샘플링 데몬(102)이 빈도 예측 유형이 수신된 이벤트에 대한 더 나은 예측자였을 것임을 결정할 때마다, 샘플링 데몬(102)은 빈도 예측 유형에 대한 점수(예를 들어, 카운터)를 증분시킬 수 있다. 샘플링 데몬(102)이 파노라마 예측 유형이 수신된 이벤트에 대한 더 나은 예측자였을 것임을 결정할 때마다, 샘플링 데몬(102)은 파노라마 예측 유형에 대한 점수(예를 들어, 카운터)를 증분시킬 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 각각의 예측 유형(예를 들어, 빈도, 파노라마)에 대해 생성된 점수들에 기초하여 디폴트 예측 유형을 결정할 수 있다. 예를 들어, 스코어보드 프로세스가 파노라마 예측 유형에 대해 더 높은 점수를 생성한다면, 파노라마가 디폴트 예측 유형으로서 할당될 것이다. 스코어보드 프로세스가 빈도 예측 유형에 대해 더 높은 점수를 생성한다면, 빈도가 디폴트 예측 유형으로서 할당될 것이다. 클라이언트가 피어 또는 시간 예측을 요청하는 경우, 클라이언트는 예측 유형(예를 들어, 파노라마, 빈도, 디폴트)을 특정할 수 있다. 클라이언트가 예측 유형을 특정하지 않는 경우, 디폴트 예측 유형이 피어 및/또는 시간 예측들을 생성하는 데 사용될 것이다.

속성 통계치

일부 구현들에서, 클라이언트는 샘플링 데몬(102)이 속성 또는 속성 값에 대한 통계치를 생성할 것을 요청할 수 있다. 예를 들어, 예측 생성과 유사하게, 클라이언트는, 속성 또는 속성 값에 대한 통계치가 생성되어야 하는 이력 윈도우를 특정할 수 있다. 샘플링 데몬(102)은 특정된 속성 또는 속성 값에 대한 통계치를 생성할 때 특정된 이력 윈도우 내에서 발생하는 속성 이벤트들을 분석할 것이다. 클라이언트 요청은 이하의 통계치 중 어느 것이 샘플링 데몬(102)에 의해 생성되어야 하는지를 특정할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 속성 또는 속성 값에 대한 "카운트" 통계치를 생성할 수 있다. 예를 들어, "카운트" 통계치는 특정된 이력 윈도우 내에서 발생하는 특정된 속성 또는 속성 값과 연관된 이벤트들의 수를 카운트할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 속성 값들에 기초하여 통계치를 생성할 수 있다. 예를 들어, 특정된 이력 윈도우 내의 속성에 대한 첫 번째 값 및/또는 마지막 값을, 클라이언트가 요청할 수 있고 샘플링 데몬(102)은 반환할 수 있다. 특정된 이력 윈도우 내의 특정된 속성과 연관된 모든 값들에 대한 최소, 최대, 평균, 모드(mode) 및 표준편차를, 클라이언트가 요청하고 샘플링 데몬(102)은 반환할 수 있다. 샘플링 데몬(102)은 어떤 값들이 요청된 백분위수들(예를 들어, 10번째, 25번째, 50번째, 75번째, 90번째 등)과 연관되는지를 생성하거나 결정할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 지속기간 통계치를 생성할 수 있다. 예를 들어, 샘플링 데몬(102)은 속성의 시작 이벤트를 속성의 중지 이벤트와 비교함으로써 속성 값과 연관된 지속기간을 결정할 수 있다. 시작 이벤트가 발생했을 때와 중지 이벤트가 발생했을 때 사이의 시간 차이는 이벤트의 지속기간일 것이다. 일부 구현들에서, 특정된 이력 윈도우 내의 특정된 속성 또는 속성 값과 연관된 모든 지속기간들에 대한 최소, 최대, 평균, 모드 및 표준편차를, 클라이언트가 요청하고 샘플링 데몬(102)은 반환할 수 있다. 샘플링 데몬(102)은 어떤 지속기간 값들이 요청된 백분위수들(예를 들어, 10번째, 25번째, 50번째, 75번째, 90번째 등)과 연관되는지를 생성하거나 결정할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 이벤트 간격 통계치를 생성할 수 있다. 예를 들어, 샘플링 데몬(102)은 속성 이벤트의 제1 발생을 속성 이벤트의 후속 발생과 비교함으로써 속성 값과 연관된 이벤트의 도달 또는 그 보고와 연관된 시간 간격을 결정할 수 있다. 제1 이벤트가 발생했을 때와 후속 이벤트가 발생했을 때 사이의 시간 차이는 이벤트의 발생들 사이의 시간 간격일 것이다. 일부 구현들에서, 특정된 이력 윈도우 내의 특정된 속성 또는 속성 값과 연관된 모든 시간 간격 값들에 대한 최소, 최대, 평균, 모드 및 표준편차를, 클라이언트가 요청하고 샘플링 데몬(102)은 반환할 수 있다. 샘플링 데몬(102)은 어떤 간격 값들이 요청된 백분위수들(예를 들어, 10번째, 25번째, 50번째, 75번째, 90번째 등)과 연관되는지를 생성하거나 결정할 수 있다.

애플리케이션을 최신 상태로 유지 - 업데이트들을 페칭(Fetching Updates)

도 4는 애플리케이션들의 백그라운드 페치 업데이트를 수행하기 위한 예시적인 시스템(400)을 예시한다. 일부 구현들에서, 모바일 디바이스(100)는, 사용자가 애플리케이션들을 호출할 것을 예상하여 애플리케이션들이 콘텐츠를 다운로드하고 그것들의 인터페이스들을 업데이트할 수 있도록, 모바일 디바이스(100)의 백그라운드 프로세스들로서 애플리케이션들을 예측적으로 개시하도록 구성될 수 있다. 예를 들면, 샘플링 데몬(102)에 의해 유지된 사용자 애플리케이션 개시 이력 데이터(예를 들어, "system.bundleId" 시작 이벤트들)는 사용자가 모바일 디바이스(100)의 애플리케이션들을 언제 호출할지를 예측(예상)하는 데 사용될 수 있다. 이러한 예측된 애플리케이션들은 사용자 호출 이전에 애플리케이션 관리자(106)에 의해 개시되어, 사용자 호출된 애플리케이션이 현재 콘텐츠를 다운로드하고 애플리케이션들의 그래픽 인터페이스들을 업데이트하는 것을 사용자가 기다릴 필요가 없게 할 수 있다.

애플리케이션을 언제 개시할지 결정 - 시간 예측

일부 구현들에서, 애플리케이션 관리자(106)는 샘플링 데몬(102)으로부터 애플리케이션 호출 예측을 요청할 수 있다. 예를 들어, 샘플링 데몬(102)은, 애플리케이션 관리자(106)로 하여금 모바일 디바이스(100) 상의 애플리케이션 개시들(예를 들어, "bundleId" 시작 이벤트들)의 시간 예측을 요청할 수 있게 하는 인터페이스를 제공할 수 있다. 샘플링 데몬(102)은 사용자가 언제 모바일 디바이스(100) 상의 애플리케이션들을 호출했는지를 나타내는 이벤트들(예를 들어, "bundleId" 시작 이벤트들)을 수신할 수 있으며, 이는 전술한 바와 같다. 애플리케이션 관리자(106)가 "bundleId" 속성에 대한 시간 예측을 요청하는 경우, 샘플링 데몬(102)은 이벤트 데이터 저장소(104)에 저장된 "bundleId" 이벤트들을 분석하여, 하루 중 언제(예를 들어, 어느 15분 타임슬롯에서) 애플리케이션들이 일반적으로 사용자에 의해 호출되는지를 결정할 수 있다. 예를 들면, 샘플링 데몬(102)은 전술한 시간 예측 메커니즘을 사용하여, 하루 중 특정 시간 또는 기간이 사용자에 의한 애플리케이션 호출을 포함할 확률을 계산할 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)는 애플리케이션 관리자(106)의 초기화 동안 샘플링 데몬(102)으로부터 "bundleId" 속성에 대한 시간 예측을 요청할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 모바일 디바이스(100)의 시동 동안 호출되거나 개시될 수 있다. 애플리케이션 관리자(106)가 초기화하는 동안, 애플리케이션 관리자(106)는 다음 24시간 동안의 애플리케이션 호출들(예를 들어, "bundleId" 시작 이벤트들)의 시간 예측을 요청할 수 있다. 초기 24시간 기간이 경과했으면, 애플리케이션 관리자(106)는 다른 24시간 시간 예측을 요청할 수 있다. 이러한 24시간 예측 사이클은 예를 들어, 모바일 디바이스(100)가 꺼질 때까지 계속될 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 24시간 기간 동안의 애플리케이션 호출(예를 들어, "bundleId" 시작 이벤트) 시간 예측을 생성할 수 있다. 예를 들면, 샘플링 데몬(102)은 24시간 기간을 96개의 15분 타임슬롯들로 분할할 수 있다. 샘플링 데몬(102)은, 샘플링 데몬(102)에 의해 수집되고 이벤트 데이터 저장소(104)에 저장된 애플리케이션 개시 이력 데이터(예를 들어, "bundleId" 시작 이벤트 데이터)에 기초하여, 동작의 이전 날들의 수(예를 들어, 1 내지 7)에 걸쳐 어느 애플리케이션들이 호출되었는지 그리고 몇 시에 애플리케이션들이 호출되었는지를 결정할 수 있다.

일부 구현들에서, 샘플링 데몬(102)이 "bundleId" 속성에 대한 시간 예측을 생성하는 경우, 각각의 15분 타임슬롯은 (예를 들어, 임의의) 애플리케이션이 그 15분 타임슬롯 내에서 호출될 확률에 따라 순위가 매겨질 수 있으며, 이는 시간 예측 섹션에서 전술한 바와 같다.

96개의 타임슬롯들 각각에 대한 애플리케이션 호출 확률들이 계산되면, 샘플링 데몬(102)은 가장 큰, 0이 아닌(non-zero) 확률들을 갖는 타임슬롯들의 수(예를 들어, 최대 64)를 선택하고 타임슬롯들을 식별하는 정보를 애플리케이션 관리자(106)에 반환할 수 있다. 예를 들면, 샘플링 데몬(102)은, 가능한(probable) 사용자 호출된 애플리케이션 개시들에 대응하는 15분 타임스롯들(예를 들어, 0보다 큰 점수를 갖는 타임슬롯들)의 시작에 대응하는 시간들의 리스트(예를 들어, 오후 12:00, 오후 1:45 등)를 애플리케이션 관리자(106)에 송신할 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 의해 제공된 타임슬롯들에 기초하여 타이머들을 설정할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 의해 식별된 타임슬롯들에 대응하는 하나 이상의 타이머(예를 들어, 알람)를 생성하거나 설정할 수 있다. 각 타이머가 울릴 때(예를 들어, 오후 12:00), 애플리케이션 관리자(106)는 (예를 들어, 슬리핑하고 있다면, 보류되어 있다면 등) 웨이크(wake)할 수 있고, 어느 애플리케이션들이 현재 15분 타임슬롯에 대해 개시되어야 하는지를 결정할 수 있다. 따라서, 타이머들은 대응하는 타임슬롯 내에서 사용자에 의해 호출될 가능성이 있는 애플리케이션들에 대한 페치 백그라운드 업데이트를 트리거할 수 있다.

일부 구현들에서, 다른 이벤트들은 애플리케이션들에 대한 페치 백그라운드 업데이트를 트리거할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 다양한 이벤트들에 대한 관심을 등록할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 셀룰러 무선장치, 기저대역 프로세서를 켜는 것 또는 네트워크 연결(예를 들어, 셀룰러 또는 Wi-Fi)을 구축하는 것에 관련된 이벤트들(예를 들어, 속성들)에 대한 관심을 등록하여, 애플리케이션 관리자(106)가 이들 이벤트들이 발생할 때 통지받을 수 있고 백그라운드 애플리케이션 개시를 트리거하여 애플리케이션 업데이트가 활성 네트워크 연결을 이용할 수 있게 할 수 있다. 모바일 디바이스(100)를 잠금해제하는 것, 디스플레이를 켜는 것 및/또는 기타 상호작용들은 백그라운드 애플리케이션 개시 및 페치 업데이트를 트리거할 수 있고, 이는 이하 더 설명되는 바와 같다. 일부 구현들에서, 애플리케이션 관리자(106)는, 임의의 백그라운드 업데이트가 이전의 분의 수(number of minutes)(예를 들어, 7) 내에서 수행되었다면 백그라운드 애플리케이션 개시 및 페치 업데이트를 트리거하지 않을 것이다.

어떤 애플리케이션들을 개시할지 결정 - 피어 예측

일부 구현들에서, 애플리케이션 관리자(106)는, 샘플링 데몬(102)이 현재 시간에 대해 개시할 애플리케이션들의 리스트를 제공할 것을 요청할 수 있다. 예를 들어, 15분 타임슬롯에 대해 타이머가 울리거나(예를 들어, 만료되거나) 트리거링 이벤트가 검출되는 경우, 애플리케이션 관리자는 샘플링 데몬(102)이 현재 타임슬롯에 대해 어느 애플리케이션들을 개시할지를 결정할 수 있도록 "bundleId" 속성에 대한 샘플링 데몬(102)으로부터의 피어 예측을 요청할 수 있다. 이어서, 샘플링 데몬(102)은, 애플리케이션 식별자들의 리스트, 및 각각의 애플리케이션이 대략 현재 시간에 사용자에 의해 호출될 확률을 나타내는 대응하는 점수들을 포함하는 피어 예측들을 생성할 수 있다.

도 5는 모바일 디바이스(100) 상의 애플리케이션들에 대한 사용자 호출 확률을 결정하기 위한 피어 예측을 예시한다. 예를 들어, 다이어그램(500)은 최근 이력 윈도우 스펙(예를 들어, 이전 2시간)에 대한 피어 예측을 예시한다. 다이어그램(530)은 일단위 이력 윈도우 스펙(예를 들어, 이전 7일 동안 매일 4시간 블록들)에 대한 피어 예측을 예시한다. 다이어그램(560)은 주단위 이력 윈도우 스펙(예를 들어, 7일마다 한번, 4시간 블록)에 대한 피어 예측을 예시한다. 일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(100) 상의 애플리케이션들에 대한 사용자 호출 확률들을 결정하기 위해 상이한 중첩하는 윈도우 스펙들에 대한 피어 예측들을 사용하여 시계열 모델링을 수행할 수 있다. 애플리케이션이 피어 예측들에서 나타나지 않으면, 애플리케이션은 0의 확률 값을 할당받을 수 있다.

일부 구현들에서, 시계열 모델링은 상이한 시간 윈도우들에 대한 피어 예측들을 생성함으로써 수행될 수 있다. 예를 들어, 최근, 일단위 및 주단위 피어 예측들은 최근, 일단위 및 주단위 이벤트 이력 윈도우 스펙들에 기초하여 생성할 수 있다. 이어서, 현재 시간에 어느 애플리케이션들을 개시할지를 결정하기 위해 최근, 일단위 및 주단위 피어 예측들이 조합될 수 있으며, 이는 이하 더 설명되는 바와 같다.

일부 구현들에서, 사용자 호출 확률들은 최근 애플리케이션 호출들에 기초하여 생성될 수 있다. 예를 들어, 사용자 호출 확률들은, 이전 2시간을 관심 기간으로서 특정하는 윈도우 스펙(예를 들어, 지난 2시간 내의 사용자가 개시한 애플리케이션 개시들)으로 "bundleId" 속성에 대한 피어 예측을 수행함으로써, 생성될 수 있다.

다이어그램(500)에 의해 예시된 바와 같이, 애플리케이션 개시 이력 데이터(예를 들어, "bundleId" 이벤트 데이터)는 이전 2시간 내에 개시되었던 애플리케이션들의 수(예를 들어, 4)를 나타낼 수 있다. 예를 들면, 점들 및 원들은 애플리케이션들을 표현할 수 있으며, 여기서 빈 원들은 단일의 특정 애플리케이션(예를 들어, 이메일, 소셜 네트워킹 애플리케이션 등)을 표현할 수 있고 빈 원들은 다른 애플리케이션의 호출을 표현한다. 최근 이력(예를 들어, 이전 2시간)을 사용하는 특정 애플리케이션과 연관된 피어 예측 확률 점수는, 이전 2시간 내에서 특정 애플리케이션의 호출 수(예를 들어, 2)를 애플리케이션 호출들의 총수(예를 들어, 4)로 나눔으로써 계산될 수 있다. 예시된 경우에서, 최근 애플리케이션 개시 이력 데이터를 사용하는 특정 애플리케이션과 연관된 확률은 2/4 또는 50%이다.

사용자 호출 확률들은 애플리케이션 개시들의 일단위 이력(예를 들어, 이전 7일 각각 동안 현재 시간 +-2시간에서 개시되었던 애플리케이션들)에 기초하여 생성될 수 있다. 예를 들어, 사용자 호출 확률들은, 하루 중 현재 시간 +-2시간(예를 들어, 4시간 반복 폭)을 24시간의 반복 빈도를 갖는(예를 들어, 24시간마다 반복 폭을 반복함) 관심 기간(예를 들어, 지난 2시간 내의 사용자 시작된 애플리케이션 개시들)으로서 특정하는 윈도우 스펙으로 "bundleId" 속성에 대한 피어 예측을 수행함으로써, 생성될 수 있다.

다이어그램(530)은 애플리케이션에 대한 사용자 호출 확률을 결정하는 데 사용될 수 있는 애플리케이션 개시들의 일단위 이력(예를 들어, "bundleId" 시작 이벤트들)을 예시한다. 예를 들면, 다이어그램(530)의 각 박스는, 특정 애플리케이션(예를 들어, 빈 원)에 대한 사용자 호출 확률(예를 들어, 피어 예측 점수)을 결정하기 위하여 분석될 수 있는 일정 수(예를 들어, 7)의 이전 날들(예를 들어, 피어 예측의 윈도우 스펙에 특정된 바와 같음) 각각에서의 시간 윈도우(예를 들어, 하루 중 현재 시간 +-2시간)를 표현한다. 일단위 이력 데이터를 사용하는 특정 애플리케이션과 연관된 확률은, 모든 윈도우들에서의 특정 애플리케이션들의 수(예를 들어, 6)를, 모든 윈도우들에서의 애플리케이션 호출들의 총수(예를 들어, 22)로 나눔으로써 계산될 수 있다. 예시된 경우에서, 일단위 개시 이력 데이터를 사용하는 특정 애플리케이션과 연관된 확률은 6/22 또는 27%이다.

사용자 호출 확률들은 애플리케이션 개시들의 주단위 이력(예를 들어, 7일 전 현재 시간 +-2시간에서 개시되었던 애플리케이션들)에 기초하여 생성될 수 있다. 예를 들어, 사용자 호출 확률들은, 하루 중 현재 시간 +-2시간(예를 들어, 4시간 반복 폭)을 7일의 반복 빈도를 갖는(예를 들어, 7일마다 반복 폭을 반복함) 관심 기간(예를 들어, 지난 2시간 내의 사용자가 개시한 애플리케이션 개시들)으로서 특정하는 윈도우 스펙으로 "bundleId" 속성에 대한 피어 예측을 수행함으로써, 생성될 수 있다.

다이어그램(560)은 애플리케이션에 대한 사용자 호출 확률을 결정하는 데 사용될 수 있는 애플리케이션 개시들의 주단위 이력(예를 들어, "bundleId" 시작 이벤트들)을 예시한다. 예를 들어, 현재 날짜 및 시간이 수요일 오후 1시이면, 애플리케이션에 대한 사용자 호출 확률(예를 들어, 피어 예측 점수)은 이전 수요일 중에 오후 1시에 또는 대략 오후 1시에서의 시간 윈도우 동안(예를 들어, +-2시간) 개시된 애플리케이션들에 기초될 수 있다. 예시된 경우에서, 주단위 애플리케이션 개시 이력 데이터를 사용하는 특정 애플리케이션(예를 들어, 빈 원)과 연관된 확률은 1/4 또는 25%이다.

일부 구현들에서, 최근, 일단위 및 주단위 사용자 호출 확률들은 각 애플리케이션에 대한 점수를 생성하기 위하여 조합될 수 있다. 예를 들면, 최근, 일단위 및 주단위 확률들은 최근(r), 일단위(d) 및 주단위(w) 확률들의 가중 평균을 계산함으로써 조합될 수 있다. 각 확률은 연관된 가중치를 가질 수 있으며, 각 가중치는 각 확률의 경험적으로 결정된 미리정의된 중요성에 대응할 수 있다. 모든 가중치들의 합은 1과 같을 수 있다. 예를 들면, 최근 개시들에 기초한 확률에 대한 가중치는 0.6일 수 있고, 일단위 확률에 대한 가중치는 0.3일 수 있으며, 주단위 확률에 대한 가중치는 0.1일 수 있다. 따라서, 조합된 확률 점수는 0.6(r), 0.3(d) 및 0.1(w)의 합(예를 들어, 점수 = 0.6r + 0.3d + 0.1w)일 수 있다.

다시 도 4를 참조하면, 확률 점수가 최근, 일단위 및 주단위 확률들에 기초하여 각 애플리케이션에 대해 결정되면, 샘플링 데몬(102)은 가장 높은 0이 아닌 확률 점수들을 갖는 구성가능한 수(예를 들어, 3)의 애플리케이션들을 백그라운드 페치 다운로드/업데이트를 수행하도록 개시하기 위해 애플리케이션 관리자(106)에 추천할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은, 백그라운드 업데이트(예를 들어, 페칭) 애플리케이션 업데이트를 지원하지 않는 전술한 애플리케이션들, 사용자가 백그라운드 업데이트를 끈 애플리케이션들, 백그라운드 업데이트에서 제외된 애플리케이션들, 및/또는 포그라운드 애플리케이션이 이미 최신일 확률이 있으므로 모바일 디바이스(100)의 디스플레이 상의 포그라운드 내에 있거나 사용자에 의해 현재 사용 중인 애플리케이션을, "무엇을 개시할지" 분석으로부터 배제할 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)가 샘플링 데몬(102)으로부터 그 추천된 애플리케이션들을 수신하면, 애플리케이션 관리자(106)는 추천된 애플리케이션들 각각을 개시해도 좋은지를 샘플링 데몬(102)에 질의할 수 있다. 샘플링 데몬(102)은 (아래에서 설명되는) 자신의 로컬 승인 제어 메커니즘을 사용하여 애플리케이션 관리자가 특정 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 추천된 애플리케이션들 중 하나를 식별하는 속성 값을 갖는 "bundleId" 속성을 샘플링 데몬(102)에 송신할 수 있고, 샘플링 데몬(102)이 속성 값에 대한 승인 제어를 수행할 것을 요청할 수 있다.

로컬 승인 제어

일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(100) 상의 속성 이벤트들에 대한 승인 제어를 수행할 수 있다. 예를 들어, 클라이언트 애플리케이션이 속성과 연관된 활동, 행동, 기능, 이벤트 등을 수행할 수 있는지 여부를 결정하기 위해, 속성 또는 속성 값에 대해 승인 제어가 수행될 수 있다. 예를 들어, 샘플링 데몬(102)의 클라이언트는 "mailapp"의 값을 갖는 속성 "bundleId"의 승인을 요청할 수 있다. 승인 요청을 수신하는 것에 응답하여, 샘플링 데몬은 클라이언트가 "mailapp" 속성 값과 연관된 활동을 수행할(예를 들어, "mailapp" 애플리케이션을 실행할) 수 있는지 여부를 결정할 수 있다.

일부 구현들에서, 승인 제어는 예산들 및 투표자(voter)들로부터의 피드백에 기초하여 수행될 수 있다. 예를 들어, 샘플링 데몬(102)이 승인 제어 요청을 수신하면, 요청은 속성 이벤트를 허용하는 것(예를 들어, 애플리케이션을 개시하는 것, "bundleId" 시작 이벤트)과 연관된 비용을 포함할 수 있다. 샘플링 데몬(102)은 시스템-범위 데이터 예산, 시스템-범위 에너지 예산 및/또는 특정 속성 예산들을 체크하여, 속성과 연관된 예산들이 속성 이벤트를 커버하기에 충분한 남아있는 크레디트를 갖는지 여부를 결정할 수 있다. 속성과 연관된 예산이 없으면(예를 들어, 속성이 예산책정된 속성이 아님), 속성 이벤트는 진행되도록 허용될 수 있다(예를 들어, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "좋음(ok)" 값을 반환할 것이다). 속성과 연관된 예산이 있으며 연관된 예산 내에 이벤트의 비용을 커버하기에 충분한 크레디트가 남아있지 않으면, 속성 이벤트는 진행하도록 허용되지 않을 것이다(예를 들어, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "아니오" 값을 반환할 것이다).

속성과 연관된 예산이 있으며 예산 내에 이벤트의 비용을 커버하기에 충분한 크레디트가 남아있는 경우, 투표자들은 속성이 진행하도록 허용하는 것에 대해 투표하도록 요청될 것이다. 모든 투표자들이 '예'로 투표하면, 속성 이벤트는 진행하도록 허용될 것이다(예를 들어, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "좋음" 값을 반환할 것이다). 임의의 투표자가 '아니오'로 투표하면, 속성 이벤트는 진행하도록 허용되지 않을 것이다(예를 들어, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "아니오" 값을 반환할 것이다). 예산 및 투표자에 관한 상세 사항들은 아래 단락에서 설명된다.

일부 구현들에서, 속성 또는 속성 값이 승인 제어 요청 전의 기간(예를 들어, 7일, 1개월 등)에서 샘플링 데몬(102)에 이벤트로 보고되지 않으면, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "절대 안됨" 값을 반환할 수 있다. 예를 들어, 샘플링 데몬(102)은 속성 또는 속성 값과 연관된 이벤트를 허용하거나 인정할 때를 결정하기 위해 시간 또는 피어 예측을 생성할 수 있다. 예를 들어, 발생할 것으로 예상되지 않는 이벤트를 선점할 필요가 없다(예를 들어, 사용자에 의해 호출되지 않을 애플리케이션들에 대한 데이터를 프리페치할 필요가 없음).

승인 제어 - 예산

일부 구현들에서, 샘플링 데몬(102)은 속성들 또는 속성 값들과 연관된 예산들에 기초하여 승인 제어를 수행할 수 있다. 예를 들어, 샘플링 데몬(102)은 속성 또는 속성 값과 연관된 예산에 기초하여 속성 또는 속성 값과 연관된 활동(예를 들어, 이벤트)을 허용(예를 들어, 인정)할지 여부를 결정할 수 있다. 일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(100)에 대해 구성된 시스템-범위 에너지 예산 및/또는 시스템-범위 데이터 예산에 기초하여 속성 또는 속성 값을 인정하는 것이 좋은지 여부를 결정할 수 있다. 샘플링 데몬(102)은, 현재 시간 기간(예를 들어, 현재 시간)에 대한 남아있는 데이터 및 에너지 예산들을 계속해서 추적하기 위한 카운터들을 포함하는, 어카운팅 데이터 저장소(402)에 예산을 저장할 수 있다. 클라이언트가 속성 또는 속성 값에 대해 수행될 승인 제어를 요청하는 경우, 클라이언트는 속성 또는 속성 값과 연관된 이벤트가 발생하도록 허용하거나 인정하는 비용을 나타내는 수를 특정할 수 있다. 속성과 연관된 예산에 충분한 크레디트가 있는 경우, 속성 이벤트는 아래에 설명된 투표자들에 의해 투표될 것이다. 속성과 연관된 예산에 충분한 크레디트가 있지 않은 경우, 속성 이벤트는 진행하도록 허용되지 않을 것이다.

시스템-범위 에너지 예산

일부 구현들에서, 샘플링 데몬(102)은 에너지 예산에 기초하여 속성 또는 속성 값을 인정해도 좋은지 여부를 결정할 수 있다. 예를 들면, 에너지 예산은 밀리암페어아워(milliamp hours)로 모바일 디바이스의 배터리의 용량의 백분율(예를 들어, 5%)일 수 있다.

일부 구현들에서, 에너지 예산은 24시간 기간 내의 각 시간에 분배될 수 있다. 예를 들면, 샘플링 데몬(102)은, 수집되고 이벤트 데이터 저장소(104)에 저장된 배터리 이용 통계치(예를 들어, "system.energy" 이벤트들)를 활용하여, 24시간 기간 내의 각 시간에 대한 통상의 이력적인 배터리 사용량을 반영하는 분배를 결정할 수 있다. 예를 들면, 각 시간은 이력적으로 또는 통계적으로 결정된 에너지 사용 분배 또는 애플리케이션 사용 예측에 기초하여 에너지 예산의 백분율이 할당될 수 있으며, 이는 전술한 바와 같다. 각 시간은 적어도 0보다 큰(예를 들어, 0.1%, 1% 등) 최소 량의 에너지 예산을 가질 것이다. 예를 들면, 에너지 예산의 10%는 데이터를 사용하지 않는 시간들에 분배될 수 있고, 에너지 예산의 나머지 90%는 이력적인 에너지 또는 애플리케이션 사용에 따라 활성의 사용 시간들에 분배될 수 있다. 각 시간이 경과함에 따라, 현재 에너지 예산은 새로운/현재 시간에 대한 에너지 예산으로 보충될 것이다. 이전 시간에서 남은 임의의 에너지 예산은 현재 시간의 예산에 추가될 것이다.

일부 구현들에서, 어카운팅 데이터 저장소(402)는 얼마나 많은 에너지 예산이 이용 가능하게 남아있는지 결정하기 위한 카운터를 포함할 수 있다. 예를 들면, 어카운팅 데이터 저장소(402)는 현재 시간에 대한 에너지 예산으로 초기화되는 하나 이상의 카운터를 포함할 수 있다. 에너지 예산이 속성 이벤트에 의해 사용되는 경우, 에너지 예산은 대응하는 양만큼 감소될 수 있다. 예를 들면, 애플리케이션 관리자(106)는 애플리케이션이 "bundleId" 시작 또는 중지 이벤트를 사용하여 개시되거나 종료될 때 샘플링 데몬(102)에 통지할 수 있다. 결국, 샘플링 데몬(102)은 애플리케이션이 개시될 때 그리고 애플리케이션이 종료될 때 전력 모니터(108)에 통지할 수 있다. 시작 및 중지 횟수에 기초하여, 전력 모니터(108)는 애플리케이션에 의해 얼마나 많은 에너지가 사용되었는지를 결정할 수 있다. 전력 모니터(108)는 애플리케이션에 의해 사용된 전력의 양을 샘플링 데몬(102)에 (예를 들어, "system.energy" 속성 이벤트를 제출함으로써) 전송할 수 있고, 샘플링 데몬(102)은 사용된 전력의 양만큼 적절한 카운터를 감소시킬 수 있다.

일부 구현들에서, 현재 시간을 위한 어떠한 에너지 예산도 남아있지 않은 경우, 샘플링 데몬(102)은 속성에 대한 승인 요청을 거절할 수 있다. 예를 들어, 어카운팅 데이터 저장소(402) 내의 에너지 예산 카운터들이 0으로 감소될 때, 에너지 예산은 남지 않으며, 에너지 예산에 묶이는 어떠한 속성들과 연관된 활동, 이벤트 등도 인정될 수 없다. 속성 이벤트의 비용을 커버하기에 충분한 에너지 예산이 현재 시간에 대해 남아있다면, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "예" 값을 반환하고 속성 이벤트가 진행하도록 허용할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은, 모바일 디바이스(100)가 외부 전력에 플러그인될 때 승인 제어 결정을 에너지 예산에 기초하지 않을 것이다. 예를 들면, 0의 남은 에너지 예산은 모바일 디바이스(100)가 외부 전력원에 플러그인될 때 속성 이벤트들을 방지하지 않을 것이다.

시스템-범위 데이터 예산

일부 구현들에서, 샘플링 데몬(102)은 데이터 예산에 기초하여 속성을 인정해도 좋은지 여부를 결정할 수 있다. 예를 들면, 샘플링 데몬(102)은, 샘플링 데몬(102)에 의해 수집되고 이벤트 데이터 저장소(104)에 저장되는 통계 데이터(예를 들어, "system.networkBytes" 속성 이벤트들)에 기초하여 모바일 디바이스(100)에 의해 소비된 네트워크 데이터의 평균량을 결정할 수 있다. 네트워크 데이터 예산은 사용자/모바일 디바이스(100)에 의해 소비되는 평균 일단위 네트워크 데이터의 백분위로서 계산될 수 있다. 대안적으로, 네트워크 데이터 예산들은 미리정의된 또는 구성가능한 값들일 수 있다.

일부 구현들에서, 네트워크 데이터 예산들은 24시간 기간 내에서 각 시간에 분배될 수 있다. 예를 들면, 각 시간은 최소 예산(예를 들어, 0.2 MB)이 할당될 수 있다. 네트워크 데이터 예산의 남은 양은 이력적인 네트워크 데이터 사용에 따라 24시간들 각각에 분배될 수 있다. 예를 들면, 샘플링 데몬(102)은 하루 중 각 시간에서 얼마나 많은 네트워크 데이터가 소비되는지를 이력적인 통계 데이터(예를 들어, "system.networkBytes" 속성 이벤트들)에 기초하여 결정하고 각 시간에서 소비된 데이터의 양들에 따라 백분율들을 할당할 수 있다. 각 시간이 경과함에 따라, 현재 데이터 예산은 새로운/현재 시간에 대한 데이터 예산으로 보충될 것이다. 이전 시간에서 남은 임의의 데이터 예산은 현재 시간의 데이터 예산에 추가될 수 있다.

일부 구현들에서, 어카운팅 데이터 저장소(402)는 네트워크 데이터 예산들에 대한 데이터 카운터들을 유지할 수 있다. 네트워크 데이터가 소비됨에 따라, 데이터 카운터들은 소비된 네트워크 데이터의 양에 따라 감소될 수 있다. 예를 들면, 소비된 네트워크 데이터의 양은 애플리케이션 관리자(106)에 의해 샘플링 데몬(102)에 제공된 애플리케이션 시작 및 중지 이벤트들(예를 들어, "bundleId" 시작 또는 중지 이벤트들)에 기초하여 결정될 수 있다. 대안적으로, 소비된 네트워크 데이터의 양은 네트워크 인터페이스를 관리하는 프로세스에 의해 제공될 수 있다(예를 들어, 네트워크 데몬(406), 백그라운드 전송 데몬(1302)). 예를 들어, 네트워크 인터페이스 관리 프로세스는 애플리케이션이 얼마나 많은 데이터를 소비하는지를 결정하기 위해 애플리케이션 시작 및 중지 이벤트들(예를 들어, "bundleId" 이벤트들)과 상관될 수 있는 "system.networkBytes" 이벤트들을 샘플링 데몬(102)에 보고할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 어느 네트워크 인터페이스 유형(예를 들어, 셀룰러 또는 Wi-Fi)이 네트워크 데이터를 소비하는 데 사용되는지를 계속해서 추적하고 네트워크 인터페이스 유형에 기초하여 소비된 네트워크 데이터의 양을 결정할 수 있다. 소비된 네트워크 데이터의 양은 각 인터페이스 유형에 할당된 가중치들 또는 계수들에 따라 조정될 수 있다. 예를 들면, 셀룰러 데이터 인터페이스 상에서 소비되는 네트워크 데이터는 일(1)의 계수가 할당될 수 있다. Wi-Fi 인터페이스 상에서 소비되는 네트워크 데이터는 십분의 일(0.1)의 계수가 할당될 수 있다. 소비된 총 네트워크 데이터는 10으로 나뉜 소비된 Wi-Fi 데이터에 소비된 셀룰러 데이터를 더함으로써 계산될 수 있다(예를 들어, 총 데이터 = 1*셀룰러 데이터 + 0.1*Wi-Fi). 따라서, Wi-Fi를 통해 소비된 데이터는 셀룰러 데이터 연결을 통해 소비된 데이터보다 훨씬 적게 데이터 예산에 영향을 줄 것이다.

일부 구현들에서, 현재 시간에 대한 어떠한 데이터 예산도 남아있지 않은 경우, 샘플링 데몬(102)은 승인 제어 요청에 "아니오" 응답으로 응답할 수 있다. 예를 들어, 어카운팅 데이터 저장소(402) 내의 데이터 예산 카운터들이 0으로 감소될 때, 데이터 예산은 남지 않으며, 데이터 예산에 묶이는 속성들과 연관된 어떠한 활동도 허용되지 않을 것이다. 속성 이벤트의 데이터 비용을 커버하기에 충분한 데이터 예산이 현재 시간에 남아있다면, 샘플링 데몬(102)은 승인 제어 요청에 "예" 응답으로 응답할 수 있다.

속성 예산

일부 구현들에서, 속성은 예산과 연관될 수 있다. 예를 들어, 미리정의된 속성 또는 커스텀(동적으로 정의된) 속성은 샘플링 데몬(102)의 API를 통해 예산과 연관될 수 있다. 샘플링 데몬(102)의 클라이언트(예를 들어, 애플리케이션, 유틸리티, 기능, 제3자 애플리케이션 등)는 속성을 클라이언트 정의된 예산과 연관시키도록 샘플링 데몬(102)에 요청할 수 있다. 예산은 예를 들어, 크레디트들의 수이다.

예산이 할당되면, 예산책정된 속성과 연관된 보고된 이벤트들은 이벤트와 연관된 비용을 나타낼 수 있고, 예산은 특정된 비용에 따라 감소될 수 있다. 예를 들어, 미리정의된 시스템 속성 "system.btlescan"은 모바일 디바이스(100)가 다른 저전력 블루투스 디바이스들로부터의 신호들에 대한 스캔을 언제 수행하는지를 나타내기 위해 모바일 디바이스(100) 상에 구성될 수 있다. 블루투스 LE 스캔은 예를 들어, 백그라운드 태스크로서 실행될 수 있다. 블루투스 LE 스캔은 블루투스 무선장치가 켜질 것을 요구하며, 이는 결국, 모바일 디바이스(100)의 배터리로부터의 에너지를 소비한다. 블루투스 LE 스캔이 너무 많은 에너지를 소비하는 것을 방지하기 위해, "btlescan" 속성은 예산(예를 들어, 24 크레디트)을 할당받을 수 있다. "btlescan" 이벤트가 생성되어 샘플링 데몬(102)에 보고될 때마다, 이벤트는 비용(예를 들어, 1)으로 보고될 수 있다. 비용은 예산에서 감산될 수 있어서, "btlescan" 속성이 이벤트에서 보고될 때마다 24의 예산은 1씩 감소된다.

일부 구현들에서, 속성 예산은 일정 기간에 걸쳐 분배될 수 있다. 예를 들어, "btlescan" 속성 예산은 24시간 기간에 걸쳐 균등하게 분배되어, "btlescan" 속성이 시간당 1 크레디트만 소비하도록 할 수 있다. 일부 구현들에서, 속성 예산은 일정 기간의 끝에서 보충될 수 있다. 예를 들어, "btlescan" 속성 예산에 대한 기간이 24시간인 경우, "btlescan" 속성 예산은 24시간마다 보충될 수 있다.

일부 구현들에서, 속성과 연관된 예산은 다른 예산의 서브세트(예를 들어, 서브-예산)일 수 있다. 예를 들어, 속성에 대한 예산은 전술한 시스템-범위 데이터 또는 시스템-범위 에너지 예산들과 같은 다른 예산의 일부분으로서 특정될 수 있다. 예를 들어, "mailapp.mailbox" 속성은 시스템에 대해 할당된 데이터 예산의 5%인 예산과 연관될 수 있다. "btlescan" 속성은 시스템에 대해 할당된 에너지 예산의 3%인 예산과 연관될 수 있다. 서브-예산(예를 들어, "mailbox" 예산)은, 서브-예산을 감소시키면 또한 수퍼-예산(super-budget)이 감소하도록, 수퍼-예산(예를 들어, 시스템 데이터 예산)에 묶일 수 있다. 일부 구현들에서, 수퍼-예산이 0으로 감소되면, 서브-예산은 또한 0으로 감소된다. 예를 들어, 시스템 데이터 예산이 0인 경우, "mailbox" 속성 예산을 감소시킬 "mailbox" 속성에 대한 어떠한 이벤트도 보고되지 않았더라도, "mailbox" 속성 예산은 또한 0일 것이다.

일부 구현들에서, 샘플링 데몬(102) 클라이언트들은, 샘플링 데몬(102)이 속성에 대해 남겨진 예산의 양을 반환할 것을 요청할 수 있다. 예를 들어, 클라이언트는 "btlescan" 속성에 대해 남아있는 예산에 대해 샘플링 데몬(102)에 요청할 수 있다. 24개의 예산책정된 크레디트 중 3개가 사용되었다면, 샘플링 데몬(102)은 값 21을 요청 클라이언트에 반환할 수 있다.

일부 구현들에서, 클라이언트는, 연관된 속성에 대한 예산 내에 크레디트가 남아있지 않을 때 특정된 수의 예산책정된 크레디트들의 비용이 드는 이벤트를 보고할 수 있다. 샘플링 데몬(102)이 예산 내에 남아있는 크레디트가 없을 때 1 크레디트의 비용이 드는 이벤트(예를 들어, "btlescan" 이벤트)를 수신하는 경우, 샘플링 데몬(102)은 예산을 감소시키고(예를 들어, -1) 이벤트를 보고한 클라이언트에 오류를 반환할 수 있다. 오류는 예를 들어, 속성이 남아있는 예산이 없음을 나타낼 수 있다.

속성 예산 형성

일부 구현들에서, 속성 예산은 사용 이력 정보에 기초하여 분배될 수 있다. 예를 들어, 이벤트들이 예산책정된 속성에 대해 보고됨에 따라, 속성에 대한 예산을 사용하기 위한 요청들(예를 들어, 비용과 연관된 이벤트들)이 시간에 따라 추적될 수 있다. 예를 들어, "btlescan" 속성에 대해 24의 예산이 할당되면, 예산은 초기에 24시간 기간에 걸쳐 균등하게 할당될 수 있으며, 이는 전술한 바와 같다. 이벤트들이 예산과 연관된 속성에 대해 시간에 따라 보고됨에 따라, 샘플링 데몬(102)은 보고된 이벤트들을 분석하여 이벤트들이 24시간 기간 중 언제 발생할 가능성이 가장 높은지를 결정할 수 있다. 예를 들어, 샘플링 데몬(102)은 "btlescan" 이벤트가 대략 오전 8시, 오후 12시 및 오후 6시에 자주 발생하지만 오전 2시에는 거의 발생하지 않음을 결정할 수 있다. 샘플링 데몬(102)은 이 이벤트 빈도 정보를 사용하여 24시간 기간에 걸쳐 "btlescan" 속성의 예산의 분배를 형성할 수 있다. 예를 들어, 샘플링 데몬은 오전 8시, 오후 12시 및 오후 6시에 대응하는 각각의 타임슬롯에 대해 2의 예산 크레디트을 할당하고, 오전 2시와 연관된 타임슬롯에 대해서는 0의 예산 크레디트를 할당할 수 있다.

승인 제어 - 투표자

일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(100) 상에서 실행중인 다른 소프트웨어(예를 들어, 플러그인, 유틸리티, 애플리케이션, 휴리스틱 프로세스)로부터의 피드백에 기초하여 승인 제어를 수행할 수 있다. 예를 들어, 승인 제어를 위한 투표자로서 샘플링 데몬(102)과 함께 작동하도록 다른 소프트웨어가 구성될 수 있다. 예를 들어, 여러 투표자들(예를 들어, 애플리케이션, 유틸리티, 데몬, 휴리스틱스 등)은 승인 제어 결정에 대해 투표하기 위해 샘플링 데몬(102)에 등록될 수 있다. 예를 들어, 샘플링 데몬(102)은 모바일 디바이스(100)의 열 상태를 모니터링하는 투표자, 모바일 디바이스(100)의 CPU 사용량을 모니터링하는 투표자 및/또는 모바일 디바이스(100)의 배터리 전력 레벨을 모니터링하는 투표자와 인터페이스하도록 구성될 수 있다. 샘플링 데몬(102)이 승인 제어 요청을 수신하는 경우, 각 투표자(예를 들어, 열, CPU 및 배터리)는 특정된 속성과 연관된 활동이 허용되어야 하는지 여부에 대해 투표하도록 요청받을 수 있다. 모든 투표자들이 '예'로 투표하면, 속성은 인정될 것이다(예를 들어, 속성과 연관된 활동이 일어나도록 허용될 것이다). 단일 투표자가 '아니오'로 투표하면, 속성은 인정되지 않을 것이다(예를 들어, 속성과 연관된 활동은 허용되지 않을 것이다). 일부 구현들에서, 투표자들은 승인 제어 시스템에 추가적 기능을 제공하기 위해 샘플링 데몬(102)에 동적으로(예를 들어, 런타임 시) 추가될 수 있는 플러그인 소프트웨어로서 구성될 수 있다. 일부 구현들에서, 투표자들은 속성 또는 속성 값과 연관된 이벤트를 인정 또는 허용할지 여부를 결정할 때 전술한 시간 및 피어 예측 메커니즘들을 사용할 수 있다.

네트워크 데몬

일부 구현들에서, 네트워크 데몬(406)은 승인 제어 투표자로서 구성될 수 있다. 네트워크 데몬(406)은, 네트워크 데몬(406)으로 하여금 샘플링 데몬(102)으로부터 투표 요청들을 수신하고 투표(예를 들어, 예, 아니오) 응답들을 샘플링 데몬(102)에 제공할 수 있게 하는 샘플링 데몬(102)의 투표 API를 사용하도록 구성될 수 있다. 예를 들어, 네트워크 데몬(406)은 속성 및/또는 속성 값을 포함하는 투표 요청을 샘플링 데몬(102)으로부터 수신할 수 있다. 네트워크 데몬(406)은, 예를 들어, 모바일 디바이스(100)가 음성 호에 연결되고 Wi-Fi 네트워크 연결에 연결되지 않을 때 샘플링 데몬(102)이 속성 또는 속성 값과 연관된 이벤트를 인정하거나 허용해서는 안된다는 것을 나타낼 수 있다. 예를 들면, 백그라운드 업데이트 프로세스들(예를 들어, 페치 프로세스들)이 음성 호의 품질을 감소시키거나 그와 간섭하는 것을 방지하기 위하여, 네트워크 데몬(406)은 사용자가 음성 호에 연결되고 Wi-Fi 연결에 연결되지 않을 때 백그라운드 업데이트 프로세스를 개시하는 것과 연관된 이벤트들(예를 들어, "bundleId" 시작 이벤트들)을 허용하지 않을 것이다. 따라서, 네트워크 데몬(406)은 모바일 디바이스(100)가 호에 연결되고 Wi-Fi에 연결되지 않을 때 투표 요청에 응답하여 "아니오" 값을 반환할 수 있다.

일부 구현들에서, 네트워크 데몬(406)은 모바일 디바이스(100)가 품질이 나쁜 셀룰러 네트워크 연결을 가질 때 샘플링 데몬(102)은 속성 이벤트를 허용 또는 인정해서는 안된다는 것을 나타낼 수 있다. 품질이 나쁜 셀룰러 연결은 전송 속도 및/또는 처리율이 미리정의된 임계값들 미만인 경우 결정될 수 있다. 예를 들면, 모바일 디바이스(100)가 품질이 나쁜 셀룰러 네트워크 연결을 갖고 Wi-Fi에 연결되지 않은 경우, 네트워크 데몬(406)은, 샘플링 데몬(102)이 투표자 요청을 할 때 "아니오" 값을 반환함으로써, 품질이 나쁜 네트워크 연결을 이용함으로써(예를 들어, 품질이 나쁜 셀룰러 연결을 통해 데이터를 다운로드하거나 업로드하는 것을 시도할 애플리케이션을 개시하는 것) 배터리 에너지 및 셀룰러 데이터를 낭비할 속성 이벤트의 승인 또는 실행을 방지할 수 있다.

일부 실시예들에서, 네트워크 데몬(406)이 품질이 나쁜 네트워크 상태 또는 네트워크 데이터 사용량 또는 시스템 성능에 영향을 미칠 소정의 다른 상태를 나타내는 정보를 갖지 않는 경우, 네트워크 데몬(406)은 요청된 속성의 승인에 대해 "예"로 투표할 수 있다.

열 데몬

일부 구현들에서, 열 데몬(110) 애플리케이션은 승인 제어 투표자로서 구성될 수 있다. 열 데몬(110)은, 열 데몬(110)으로 하여금 샘플링 데몬(102)으로부터 투표 요청들을 수신하고 투표(예를 들어, 예, 아니오) 응답들을 샘플링 데몬(102)에 제공할 수 있게 하는 샘플링 데몬(102)의 투표 API를 사용하도록 구성될 수 있다. 예를 들어, 열 데몬은 속성 및/또는 속성 값을 포함하는 투표 요청을 샘플링 데몬(102)으로부터 수신할 수 있다. 열 데몬(110)은, 열 데몬(110)이 열 이벤트를 검출했을 때 샘플링 데몬(102)이 속성 또는 속성 값과 관련된 이벤트를 인정하거나 허용해서는 안된다는 것을 나타낼 수 있다. 예를 들어, 열 데몬(110)은 모바일 디바이스(100)의 온도를 모니터링할 수 있고, "thermalLevel" 속성 및 대응하는 온도 값을 포함하는 이벤트들을 생성함으로써 샘플링 데몬(102)에 온도 값들을 보고할 수 있다.

일부 구현들에서, 열 데몬(110)이 모바일 디바이스(100)의 온도가 임계 온도 값을 초과함을 결정하는 경우, 열 데몬(110)은, 또한 샘플링 데몬(102)이 열 데몬(110)에 속성(예를 들어, "bundleId") 이벤트에 대해 투표하기 위한 요청을 송신할 때 "아니오" 값을 반환함으로써, 열 데몬(102)이 모바일 디바이스(100)의 동작 온도를 증가시킬 수 있는 속성 이벤트들을 허용하는 것을 방지할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 비정상적 열 상태가 현재 존재할 때 단지 열 데몬(110)으로부터 투표를 요구할 것이다. 예를 들어, 샘플링 데몬(102)은 모바일 디바이스(100)가 정상적 열 상태에서 동작하고 있는지 여부를 나타내는 열 상태 값(예를 들어, 참, 거짓)을 유지할 수 있다. 모바일 디바이스(100)의 현재 열 상태가 정상인 경우, 열 상태 값은 예를 들어, 참일 수 있다. 모바일 디바이스(100)의 현재 열 상태가 비정상인 경우(예를 들어, 임계 온도 초과로, 너무 높은), 열 상태 값은 거짓일 수 있다. 초기에, 열 상태 값은 참(예를 들어, 정상 동작 온도)으로 설정될 수 있다. 동작 온도가 임계 온도를 초과하여 상승했음을 검출하면, 열 데몬(110)은 비정상적 동작 온도(예를 들어, 거짓)를 나타내는 열 상태 값에 대한 업데이트된 값을 샘플링 데몬(102)에 송신할 수 있다. 모바일 디바이스(100)가 임계 온도보다 낮은 온도로 냉각되면, 열 데몬(110)은 정상 동작 온도(예를 들어, 참)를 나타내도록 열 상태 값을 업데이트할 수 있다.

샘플링 데몬(102)이 속성에 대한 승인 제어 요청을 수신하는 경우, 샘플링 데몬(102)은 온도 상태 값을 체크하여 열 데몬(110)에게 속성 이벤트의 승인(허용)에 대해 투표할 것을 요구할지 여부를 결정할 수 있다. 열 상태 값이 정상 동작 온도를 나타내는 경우(예를 들어, 값이 참), 샘플링 데몬(102)은 열 상태 값을 열 데몬(110)으로부터의 "예" 투표로서 해석할 것이다.

열 상태 값이 비정상 동작 온도를 나타내는 경우(예를 들어, 값이 거짓), 샘플링 데몬(102)은 열 데몬(110)이 특정 속성 또는 속성 값에 대해 투표할 수 있도록 열 데몬(110)에 속성 및/또는 속성 값을 송신할 것이다.

일부 구현들에서, 열 데몬(110)은 모바일 디바이스(100)의 현재 열 상태 및 속성에 대한 피어 예측에 기초하여 속성들 및/또는 속성 값들에 대해 어떻게 투표할지를(예를 들어, 예, 아니오) 결정할 수 있다. 예를 들어, 열 데몬(110)은 샘플링 데몬(102)으로부터 속성에 대한 피어 예측을 요청할 수 있다. 열 데몬(110)은 관심 기간 내에 현재 시간(예를 들어, +-1시간, 2시간 등)을 포함하는 윈도우 스펙을 생성함으로써 현재 시간에 대한 피어 예측을 요청할 수 있다. 열 데몬(110)은, 관심 기간에서 나타나는 속성의 각 값에 대한 가능성 점수들을 나타내는 피어 예측을 샘플링 데몬(102)으로부터 수신할 수 있다. 예를 들어, 열 데몬(110)이 "bundleId" 속성에 대한 피어 예측을 요청하는 경우, 열 데몬(110)은 "bundleId" 값들(예를 들어, 애플리케이션 식별자들) 및 연관된 예측(예를 들어, 확률, 가능성) 점수들의 리스트를 수신할 수 있다. 예를 들어, 관심 기간 동안, 속성 값들 "mailapp", "contacts", "calendar", "webbrowser", "mailapp", "webbrowser", "mailapp"을 갖는 "bundleId" 이벤트들이 발생하는 경우, "mailapp"이 발생하는 상대적 가능성(즉, 점수)은 0.43(예를 들어, 3/7)이고, "webbrowser"가 발생하는 상대적 가능성은 0.29(예를 들어, 2/7)이며, "contacts" 또는 "calendar"가 발생하는 상대적 가능성들은 0.14(예를 들어, 1/7)이다. 일부 구현들에서, 열 데몬(110)은 점수에 따라 속성 값들의 리스트를 순서화할 수 있다(예를 들어, 상단에서 최고 점수, 하단에서 최저 점수). 예를 들어, 위의 "bundleId" 속성 값들에 대한 순서화된 리스트는 위에서 아래로 다음과 같다: "mailapp"; "webbrowser"; "contacts"; 및 "calendar".

일부 구현들에서, 열 데몬(110)은 속성 값이 순서화된 리스트 내에서 어디에 있는지에 기초하여 속성 값에 대해 언제 예(yes)로 투표할지를 결정할 수 있다. 예를 들어, 열 데몬(110)에 의해 고려 중인 속성 값이 샘플링 데몬(102)으로부터 수신된 피어 예측 리스트 내에 있지 않은 경우, 속성 값은 열 데몬(110)으로부터 '아니오' 투표를 받을 것이다. 속성 값이 피어 예측 리스트 내에 있고 리스트 내의 임계 레벨(예를 들어, 지수) 미만인 경우(예를 들어, 점수들에 기초한 속성들의 하위 25% 내), 열 데몬(110)은 속성에 대해 '아니오'로 투표할 것이다. 속성 값이 피어 예측 리스트 내에 있고 리스트 내의 임계 레벨 초과인 경우(예를 들어, 점수들에 기초한 속성들의 상위 75% 내), 열 데몬(110)은 속성에 대해 '예'로 투표할 것이다. 투표가 결정되면, 열 데몬(110)은 샘플링 데몬(102)에 '예'(예를 들어, 참) 또는 '아니오'(예를 들어, 거짓) 투표를 반환할 것이다.

일부 실시예들에서, 열 데몬(110)은 모든 속성 값들에 대해 '아니오'로 투표하는 것을 피하기 위해(예를 들어, 일부 속성 이벤트들이 발생할 수 있도록) 최대 임계 레벨로 구성될 수 있다. 최대 임계 레벨은 순서화된 피어 예측 리스트에서 속성 값들의 50%(예를 들어, 상위 50%는 '예' 투표를 얻고, 하위 50%는 '아니오' 투표를 얻음)일 수 있다. 따라서, 열 데몬(110)은 '아니오' 투표를 수신할 속성 값들로부터 '예' 투표를 수신할 속성 값들을 분리시키는 임계 레벨을, 최저 점수들을 갖는 속성 값들의 0%에서 50%까지 조정할 수 있다.

일부 구현들에서, '예' 또는 '아니오' 투표들을 결정하기 위한 임계 레벨은 모바일 디바이스(100)의 열 레벨(예를 들어, 온도)에 비례할 수 있다. 예를 들어, 열 데몬(110)은 최대 동작 열 레벨(L_h) 및 정상 동작 레벨(L_n)로 구성될 수 있다. 열 데몬(110)은 현재의 동작 열 레벨(L_c)을 결정할 수 있고, 모바일 디바이스(100)가 현재 동작하고 있는 열 범위(예를 들어, L_h-L_n)의 백분위수(예를 들어, L_c-L_n / L_h-L_n = %)를 결정할 수 있다. 열 데몬(110)은 계산된 백분위수를 사용하여 0-50% 속성 값들의 어느 부분이 '아니오' 투표를 받아야 하는지를 결정할 수 있다. 예를 들어, 현재의 동작 열 레벨이 열 범위의 65%인 것으로 계산되면, 피어 예측 점수에 의한 속성 값들의 하위 32.5%는 열 데몬(110)으로부터 '아니오' 투표를 받을 것이다. 따라서, 가장 중요한 속성 값들이 '예' 투표를 받는 반면에 가장 중요하지 않은 속성 값들은 '아니오' 투표를 받을 것이다. 위의 "bundleId" 예를 다시 참조하면, 위의 "bundleId" 속성 값들의 순서화된 리스트가 위에서 아래로 "mailapp"' "webbrowser"' "contacts"' 및 "calendar"인 경우, "calendar"는 '아니오' 투표를 받을 것이고, "mailapp", "webbrowser", 및 "contacts"는 '아니오' 투표를 받을 것이다(예를 들어, "mailapp", "webbrowser", 및 "contacts"는 가장 많이 사용되는 애플리케이션들이다). 예를 들어, 애플리케이션 관리자(106)가 어떤 애플리케이션들을 개시할지를 결정하기 위해 "bundleId" 속성에 대한 승인 제어 요청을 했다면, "mailapp", "webbrowser", 및 "contacts" 애플리케이션들이 개시될 것이고 "calendar" 애플리케이션은 개시되지 않을 것이다.

다른 예로서, 열 데몬(110)은 "mailapp.mailbox" 속성에 대해 투표하도록 요청될 수 있다. 가장 자주 액세스되는 폴더로부터 가장 덜 자주 액세스되는 폴더를 나타내는 메일 폴더들의 순서화된 리스트(예를 들어, "inbox"; "personal"; "work"; "family"; "spam"; 및 "trash")를 생성하는 "mailapp.mailbox" 속성 값들에 대해, 피어 예측이 생성될 수 있다. 속성 값들의 하위 32.5%가 '아니오' 투표를 받게 되면, "spam" 및 "trash"는 '아니오' 투표를 받을 것이다. 예를 들어, "mailbox" 애플리케이션이 어느 폴더들에 대해 이메일을 페치할지를 결정하기 위해 "mailapp.mailbox" 속성에 대한 승인 제어 요청을 했다면, "mailapp" 애플리케이션은 "inbox", "personal" "work", 및 "family" 폴더들에 대한 이메일을 페치할 것이며 "spam" 및 "trash" 폴더들에 대한 이메일은 페치하지 않을 것이다. 일부 구현들에서, 열 데몬(110)으로부터 '아니오' 투표를 받은 속성들 또는 속성 값들은, 샘플링 데몬(102)에 의해 유지되는 열 상태 값이 정상 동작 온도(예를 들어, 참 값)를 나타내도록 리셋될 때 통지될 수 있다. 예를 들어, 샘플링 데몬(102)은 '아니오' 투표를 받은 클라이언트들, 속성들 및 속성 값들을 식별하는 데이터를 저장할 수 있다. 열 데몬(110)으로부터 업데이트된 열 상태 값(예를 들어, 참)을 수신하면, 샘플링 데몬(102)은 이전에 거절된 속성 또는 속성 값에 대한 다른 승인 제어 요청을 시도하도록 클라이언트에게 프롬프트하기 위해 '아니오' 투표를 받은 클라이언트들에게 통지를 송신할 수 있다. 일부 구현들에서, 클라이언트들은 샘플링 데몬(102)으로부터의 프롬프트 없이 승인 제어 요청을 재송신할 수 있다. 예를 들어, 클라이언트는 일정 기간이 경과한 후 클라이언트로 하여금 승인 제어 요청을 재시도하게 하는 내부 타이머를 가질 수 있다.

활동 모니터

일부 구현들에서, 활동 모니터 애플리케이션(408)은 승인 제어 투표자로서 구성될 수 있다. 활동 모니터(408)는, 활동 모니터(408)가 샘플링 데몬(102)으로부터 투표 요청들을 수신하고 투표(예를 들어, 예, 아니오) 응답들을 샘플링 데몬(102)에 제공할 수 있게 하는 샘플링 데몬(102)의 투표 API를 사용하도록 구성될 수 있다. 예를 들어, 활동 모니터(408)는 속성 및/또는 속성 값을 포함하는 투표 요청을 샘플링 데몬(102)으로부터 수신할 수 있다. 활동 모니터(408)는, 모바일 디바이스(100)가 메모리 리소스들 또는 CPU 리소스들의 임계량(예를 들어, 90%) 초과를 사용하고 있을 때 샘플링 데몬(102)이 속성 또는 속성 값과 연관된 이벤트를 인정하거나 허용해서는 안된다는 것을 나타낼 수 있다. 예를 들면, 모바일 디바이스(100)가 모바일 디바이스(100)의 메모리 리소스들 또는 CPU 리소스들의 대부분을 사용하고 있는 많은 애플리케이션들 또는 프로세스들을 이미 실행하고 있으면, 백그라운드에서 추가 애플리케이션들을 개시하는 것은 남아있는 메모리 리소스들을 다 써버림으로써 모바일 디바이스(100)의 성능을 감소시킬 가능성이 있을 것이다. 따라서, 활동 모니터(408)가 메모리 또는 CPU 사용량이 임계값(예를 들어, 75%)을 초과함을 결정하는 경우, 활동 모니터(408)는, 샘플링 데몬(102)이 "bundleId" 속성 이벤트에 대해 투표하기 위한 요청을 송신할 때 "아니오" 값을 반환함으로써, 애플리케이션 관리자(106)가 추가 애플리케이션들을 개시하는 것을 방지할 수 있다. 활동 모니터(408)가 모바일 디바이스(100)의 메모리 및/또는 CPU 리소스들이 임계 사용량보다 낮음을 결정하는 경우, 활동 모니터(408)는 샘플링 데몬(102)으로부터의 투표 요청에 응답하여 "예" 값을 반환할 수 있다.

백그라운드 페치 애플리케이션을 개시

일부 구현들에서, 애플리케이션 관리자(106)가 샘플링 데몬(102)에 승인 제어 요청을 하고 "예" 응답을 수신하는 경우, 애플리케이션 관리자(106)는 모바일 디바이스(100)의 동작 환경의 백그라운드에서 식별된 애플리케이션(예를 들어, "bundleId" 속성 값에 의해 식별된 바와 같은, 애플리케이션(108))을 호출하거나 개시할 수 있다. 예를 들면, 애플리케이션(108)은, 애플리케이션(108)이 개시되었는지가 사용자에게 명백하게 되지 않도록, 백그라운드에서 개시될 수 있다. 이어서, 애플리케이션(108)은 네트워크(예를 들어, 인터넷)를 통해 콘텐츠 서버(404)와 통신하여, 사용자에게 표시하기 위한 업데이트된 콘텐츠를 다운로드할 수 있다. 따라서, 사용자가 애플리케이션(108)을 후속적으로 선택하는 경우(예를 들어, 애플리케이션을 포그라운드로 가져옴), 사용자는, 애플리케이션(108)이 서버(404)로부터 콘텐츠를 다운로드하고 애플리케이션의 사용자 인터페이스들을 리프레시하도록 기다릴 필요 없이 현재 및 최신 콘텐츠를 제시받을 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)는, 모바일 디바이스(100)가 충전되고 있고 Wi-Fi에 연결되어 있을 때 백그라운드 페치 인에이블된 애플리케이션들을 개시하도록 구성될 수 있다. 예를 들면, 샘플링 데몬(102)은 모바일 디바이스(100)가 (예를 들어, "cablePlugin" 속성 이벤트들에 기초하여) 외부 전력원에 연결되고 (예를 들어, 수신된 이벤트들에 기초하여) Wi-Fi를 통해 네트워크(예를 들어, 인터넷)에 연결되는 때를 결정할 수 있고, 애플리케이션 관리자(106)로 하여금 이전 시간의 양(예를 들어, 7일) 내에서 사용된 페치 인에이블된 애플리케이션들을 개시하게 하는 신호를 애플리케이션 관리자(106)에 송신할 수 있다.

예시적인 백그라운드 페치 프로세스

도 6은 백그라운드 업데이트들을 수행하기 위하여 애플리케이션들을 예측적으로 개시하기 위한 예시적인 프로세스(600)의 흐름도이다. 예를 들면, 프로세스(600)는 도 4의 콘텐츠 서버(404)와 같은 네트워크 리소스들로부터 데이터 업데이트들을 페치하도록 구성된 백그라운드 애플리케이션들을 언제 개시할지를 결정하기 위해 애플리케이션 관리자(106) 및 샘플링 데몬(102)에 의해 수행될 수 있다. 프로세스(600)의 단계들에 관련된 추가 설명은 위에서 도 4 및 도 5를 참조하여 발견될 수 있다.

단계(602)에서, 애플리케이션 관리자(106)는 샘플링 데몬(102)으로부터 애플리케이션 호출 예측을 수신할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 모바일 디바이스(100)의 시동 동안 개시될 수 있다. 그것의 초기화 동안, 애플리케이션 관리자(106)는 다음 24시간 기간에 걸쳐 모바일 디바이스(100)의 사용자에 의해 호출될 가능성이 있는 애플리케이션들의 예측을 요청할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 속성 "bundleId"에 대한 시간 예측을 요청할 수 있다. 이러한 예측은 애플리케이션들을 언제 개시할지를 나타낼 수 있다. 예를 들어, 24시간 기간은 15분 블록들로 분할될 수 있고, 각 15분 블록은 사용자가 15분 블록 동안 애플리케이션을 호출할 확률과 연관될 수 있다. 애플리케이션 관리자(106)로 반환된 예측은 사용자가 애플리케이션을 호출할 가능성이 있는 시간의 64개의 15분 블록들까지 식별할 수 있다.

단계(604)에서, 애플리케이션 관리자(106)는 애플리케이션 개시 예측에 기초하여 타이머들을 설정할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 의해 애플리케이션 관리자(106)로 반환된 애플리케이션 개시 예측에서 식별된 15분 블록들 각각에 대하여 타이머 또는 알람을 설정할 수 있다.

단계(606)에서, 애플리케이션 관리자(106)는 무슨 애플리케이션들을 개시할지를 식별할 것을 샘플링 데몬(102)에 요청할 수 있다. 예를 들면, 타이머가 만료되거나 알람이 울리는 경우, 애플리케이션 관리자는, 슬리핑하고 있으면 또는 보류되어 있으면, 웨이크할 수 있고, 시간의 현재 15분 블록에 대해 개시할 애플리케이션들의 리스트를 샘플링 데몬(102)으로부터 요청할 수 있다. 샘플링 데몬(102)은 모바일 디바이스(100) 상의 백그라운드에서 개시되어야 하는 애플리케이션들의 리스트를 반환할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 속성 "bundleId"에 대한 피어 예측을 요청할 수 있다. 피어 예측은 현재의 15분 타임슬롯에서 "bundleId" 속성의 어떤 값들이 보고될 가능성이 가장 높은지(예를 들어, 어떤 애플리케이션들이 사용자에 의해 호출될 가능성이 가장 높은지)를 나타낼 수 있다.

단계(607)에서, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 애플리케이션을 개시해도 좋은지 여부를 질의하는 요청을 송신할 수 있다. 예를 들면, "bundleId" 피어 예측 요청에 대한 응답으로 샘플링 데몬(102)에 의해 식별된 각 애플리케이션에 대하여, 애플리케이션 관리자(106)는 애플리케이션을 개시해도 좋은지 여부를 샘플링 데몬(102)에 질의할 수 있다. 예를 들어, 애플리케이션 관리자(106)는, 샘플링 데몬(102)이 애플리케이션 관리자(106)가 개시하려고 시도하고 있는 애플리케이션에 대응하는 "bundleId" 속성의 특정 값에 대한 승인 제어를 수행할 것을 요청할 수 있다. 샘플링 데몬(102)은 애플리케이션을 개시해도 좋다면 승인 제어 요청으로부터 "예"를, 애플리케이션을 개시해서는 안된다면 "아니오"를, 또는 애플리케이션을 개시해서는 절대 안된다면 "절대 안됨(never)"을 반환할 수 있다.

단계(610)에서, 애플리케이션 관리자(106)는 애플리케이션을 개시할 수 있다. 예를 들면, 샘플링 데몬(102)이 승인 제어 요청에 대한 "좋음"(예를 들어, 좋음, 예, 참 등) 응답을 반환하는 경우, 애플리케이션 관리자(106)는 모바일 디바이스(100)의 백그라운드 프로세스로서 애플리케이션을 개시할 것이다. 샘플링 데몬(102)이 승인 제어 요청에 대해 "아니오" 또는 "절대 안됨" 응답을 반환하면, 애플리케이션 관리자(106)는 애플리케이션을 개시하지 않을 것이다.

단계(612)에서, 애플리케이션 관리자(106)는 애플리케이션 개시 통지를 샘플링 데몬(102)에 전송할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 개시된 애플리케이션의 실행을 기록하기 위해 샘플링 데몬(102)에 "bundleId" 시작 이벤트를 전송할 수 있다.

단계(614)에서, 애플리케이션 관리자(106)는 개시된 애플리케이션이 종료되었음을 검출할 수 있다. 예를 들면, 애플리케이션 관리자(106)는 개시된 애플리케이션이 모바일 디바이스(100) 상에서 더 이상 실행되지 않는 때를 결정할 수 있다.

단계(616)에서, 애플리케이션 관리자(106)는 애플리케이션 종료 통지를 샘플링 데몬(102)에 전송할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 애플리케이션의 종료를 기록하기 위해 샘플링 데몬(102)에 "bundleId" 종료 이벤트를 전송할 수 있다.

도 7은 모바일 디바이스(100) 상에서 애플리케이션들을 언제 개시할지를 결정하기 위한 예시적인 프로세스(700)의 흐름도이다. 예를 들면, 프로세스(700)는 애플리케이션을 언제 개시할지, 무슨 애플리케이션을 개시해야 하는지, 그리고 애플리케이션 사용 통계치(예를 들어, "bundleId" 속성 이벤트 데이터), 데이터와 에너지 예산들, 및 모바일 디바이스 동작 및 환경 상태들에 기초하여 애플리케이션들을 개시해도 좋은지 여부를 결정하는 데 사용될 수 있으며, 이는 도 4를 참조하여 상세하게 전술한 바와 같다.

단계(702)에서, 샘플링 데몬(102)은 애플리케이션 관리자(106)로부터 애플리케이션 개시 예측 요청을 수신할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 샘플링 데몬(102)으로부터 다음 24시간 동안 "bundleId" 속성에 대한 시간 예측을 요청할 수 있다. 24시간 기간이 경과했으면, 애플리케이션 관리자(106)는 후속 24시간 동안 "bundleId" 속성에 대한 시간 예측을 요청할 수 있다. 예를 들어, 애플리케이션 관리자(106)는 24시간마다 "bundleId" 속성에 대한 시간 예측을 요청할 수 있다.

단계(704)에서, 샘플링 데몬(102)은 애플리케이션 개시 예측을 결정할 수 있다. 예를 들면, 애플리케이션 개시 예측(예를 들어, "bundleId" 속성에 대한 시간 예측)은 사용자 시작된 애플리케이션 개시들이 24시간 기간 동안 언제 발생할 가능성이 있는지를 예측하는 데 사용될 수 있다. 24시간 기간은 15분 시간 블록들로 분할될 수 있다. 각각의 15분 시간 블록(예를 들어, 24시간 기간 내에 96개의 15분 시간 블록들이 있음)에 대하여, 샘플링 데몬(102)은 이력적인 사용자 호출 통계치(예를 들어, "bundleId" 시작 이벤트들)를 사용하여 사용자 시작된 애플리케이션 개시가 15분 시간 블록에서 발생할 확률을 결정할 수 있으며, 이는 도 4를 참조하여 전술한 바와 같다.

단계(706)에서, 샘플링 데몬(102)은 애플리케이션 개시 예측을 애플리케이션 관리자(106)에 전송할 수 있다. 예를 들면, 샘플링 데몬(102)은 사용자 시작된 애플리케이션 개시의 가장 높은 0이 아닌 확률을 갖는 최대 64개의 15분 블록들을 선택할 수 있다. 선택된 15분 블록들 각각은 15분 블록에 대한 시작 시간(예를 들어, 오후 12:45)에 의해 식별될 수 있다. 샘플링 데몬(102)은 애플리케이션 개시 예측(예를 들어, "bundleId" 속성에 대한 시간 예측)으로서 15분 블록 식별자들의 리스트를 애플리케이션 관리자(106)에 송신할 수 있다.

단계(708)에서, 샘플링 데몬(102)은 현재 시간에 무슨 애플리케이션들을 개시할지에 대한 요청을 수신할 수 있다. 예를 들면, 애플리케이션 관리자(106)는, 현재 시간에 또는 대략 현재 시간에 어느 애플리케이션들이 개시되어야 하는지를 샘플링 데몬(102)이 결정하도록 하기 위해, 샘플링 데몬(102)에 요청을 송신할 수 있다. 예를 들어, 요청은 현재 15분 타임슬롯에 대한 "bundleId" 속성에 대한 피어 예측에 대한 요청일 수 있다.

단계(710)에서, 샘플링 데몬(102)은 이력적인 이벤트 데이터에 기초하여 현재 시간에 대해 애플리케이션들에 점수를 매길 수 있다. 샘플링 데몬(102)은 샘플링 데몬(102)에 의해 수집된 이력적인 사용자 시작된 애플리케이션 개시 데이터(예를 들어, "bundleId" 속성 시작 이벤트 데이터)에 기초하여 가까운 미래에 사용자가 어느 애플리케이션들을 개시할 가능성이 있는지를 결정할 수 있다. 샘플링 데몬(102)은 최근 애플리케이션 개시 데이터, 일단위 애플리케이션 개시 데이터 및/또는 주단위 애플리케이션 개시 데이터를 활용하여, 사용자가 현재 시간에 또는 대략 현재 시간에 애플리케이션을 호출할 이력적인 가능성에 기초하여 애플리케이션들에 점수를 매길 수 있으며, 이는 도 4 및 도 5를 참조하여 전술한 바와 같다.

단계(712)에서, 샘플링 데몬(102)은 애플리케이션들 및 애플리케이션 점수들을 애플리케이션 관리자(106)에 전송할 수 있다. 예를 들면, 샘플링 데몬(102)은 가장 높은 점수들(예를 들어, 사용자에 의해 호출될 가장 높은 확률)을 갖는 애플리케이션들(예를 들어, "bundleId" 속성 값들)의 수(예를 들어, 3)를 선택하여 애플리케이션 관리자(106)에 전송할 수 있다. 샘플링 데몬(102)은 이전 시간 기간(예를 들어, 이전 5분) 내에서 개시된 애플리케이션들을 배제할 수 있다. 샘플링 데몬(102)은 가장 높은 점수가 매겨진 애플리케이션들 및 그것들 각자의 점수들을 식별하는 정보를 애플리케이션 관리자(106)에 전송할 수 있으며, 이는 도 4를 참조하여 전술한 바와 같다.

단계(714)에서, 샘플링 데몬(102)은 애플리케이션을 개시해도 좋은지 여부를 결정하기 위해 애플리케이션 관리자(106)로부터 요청을 수신할 수 있다. 예를 들어, 샘플링 데몬(102)은 애플리케이션(예를 들어, "bundleId" 값)을 식별하는 승인 제어 요청을 수신할 수 있다.

단계(716)에서, 샘플링 데몬(102)은 현재 모바일 디바이스 상태 및 예산들이 애플리케이션 개시를 허용함을 결정할 수 있다. 예를 들어, 승인 제어 요청에 응답하여, 샘플링 데몬(102)은 시스템-범위 데이터 및 에너지 예산들, 속성 예산들 및 투표자 피드백을 체크하여, 애플리케이션이 모바일 디바이스(100) 상의 백그라운드 태스크로서 개시되어야 하는지 여부를 결정할 수 있으며, 이는 도 4를 참조하여 위에서 상세히 기술된 바와 같다.

단계(718)에서, 샘플링 데몬(102)은 식별된 애플리케이션을 개시해도 좋다는 것을 나타내는 응답을 애플리케이션 관리자(106)에 전송할 수 있다. 예를 들면, 상태들이 백그라운드 애플리케이션 개시에 대해 양호하면, 샘플링 데몬(102)은 애플리케이션 관리자(106)가 식별된 애플리케이션을 개시할 수 있도록 승인 제어 요청에 응답하여 "예" 값(예를 들어, 좋음, 예, 참 등)을 애플리케이션 관리자(106)에 반환할 수 있다.

단기간 트렌딩

일부 구현들에서, 샘플링 데몬(102)은 속성들이 트렌딩한 때를 검출하도록 구성될 수 있다. 예를 들어, 클라이언트 애플리케이션은 특정 속성에 대한 관심을 샘플링 데몬(102)에 등록할 수 있다. 샘플링 데몬(102)이 특정 속성이 트렌딩하다는 것을 검출하는 경우, 샘플링 데몬(102)은 특정 속성이 트렌딩하다는 것을 클라이언트에 통지할 수 있다.

예를 들어, 애플리케이션 관리자(106)는 "bundleId" 속성(또는 "bundleId" 속성의 특정 값)에 대한 관심을 등록할 수 있다. 샘플링 데몬(102)이 "bundleId" 속성(또는 그 값)이 트렌딩하다는 것을 결정하는 경우, 샘플링 데몬(102)은 애플리케이션 관리자(106)에게 트렌드를 통지하여, 애플리케이션 관리자(106)가 모바일 디바이스(100) 의 백그라운드에서 트렌딩 애플리케이션을 예측적으로 개시하도록 할 수 있다. 예를 들면, 애플리케이션은 애플리케이션이 모바일 디바이스(100)의 사용자에 의해 반복적으로 호출되고 있다면 트렌딩하다. 일부 경우들에서, 트렌딩 애플리케이션은, 신규 애플리케이션이거나 또는, 트렌드 이전에, 전술한 "bundleId" 속성 피어 예측에 포함될 수 없는 거의 사용되지 않은 애플리케이션이다. 따라서, 트렌딩 애플리케이션은 전술한 애플리케이션 개시 예측 방법들을 사용하여 최신상태로 유지되지 않을 수도 있다.

속성 트렌드 검출의 목적은 샘플링 데몬(102)에 반복적으로 보고되는 속성들(예를 들어, 속성 이벤트들)을 검출하는 것, 및 그를 이용하여 속성들이 개시되는 대략적인 카덴스(cadence)(예를 들어, 주기성), 보다 작은 카덴스를 보고하는 것 위주로 결정하는 것이다. 샘플링 데몬(102)에 반복적으로 보고되고 있는 속성들은 "트렌딩"으로 지칭된다. 이어서 결정된 카덴스는, 트렌딩 속성과 연관된 다음 이벤트를 예상하여 기능들 또는 동작들을 수행하기 위해 샘플링 데몬(102) 클라이언트들에 의해 사용될 수 있다.

예를 들어, 결정된 카덴스는, 사용자가 애플리케이션들을 호출할 때 애플리케이션들이 업데이트되도록, 애플리케이션 관리자(106)를 트리거하여 백그라운드에서 트렌딩 애플리케이션들을 개시할 타이머들을 설정하기 위하여 애플리케이션 관리자(106)에 의해 사용될 수 있으며, 이는 전술한 바와 같다. 예를 들면, 카덴스가 애플리케이션에 대해 5분이면, 애플리케이션 관리자(106)는, 4분마다 만료될 것이고 애플리케이션 관리자(106)로 하여금 애플리케이션이 업데이트된 콘텐츠를 수신하고 사용자에 의해 다시 호출되기 전에 애플리케이션의 인터페이스들을 업데이트할 수 있도록 애플리케이션을 개시하게 할 타이머를 설정할 수 있다.

일부 구현들에서, 본 명세서에 설명된 트렌드 검출 메커니즘들은 반복되는 소프트웨어 또는 네트워크 통지들, 애플리케이션 충돌들 등과 같은, 애플리케이션 개시들 이외의 기타 시스템 이벤트 트렌드들을 검출하는 데 사용될 수 있다. 예를 들어, 클라이언트들은 임의의 속성 또는 속성 값에 대한 관심을 등록할 수 있고, 관심 속성들이 트렌딩할 때 통지들을 수신할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 다수의 속성들의 행동을 추적하는 데 사용될 수 있는 트렌딩 표를 유지할 수 있다. 트렌딩 표는 속성 값 식별 필드(attribute value identification field; ATTID), 상태 필드(STATE), 마지막 개시 타임스탬프(last launch timestamp; LLT), 개시들 사이의 시간의 양을 나타내는 개시-간 카덴스(inter-launch cadence; ILC), 및 신뢰성(confidence) 필드(C)를 포함할 수 있다.

도 8은 트렌딩 표 내의 엔트리(예를 들어, 애플리케이션)에 대한 상태 전이들을 예시하는 흐름도(800)이다. 우선 단계(802)에서, 트렌딩 표는, ATTID, LLT, ILC 및 C 필드들이 비어있고(예를 들어, N/A), STATE가 "무효"(I)로 설정된 빈 엔트리들(예를 들어, 기록들)을 포함할 수 있다. 속성 이벤트가 시간(t)에서 보고되는 경우, 트렌딩 표는 이용 가능한 엔트리(예를 들어, 상태(I)에서의 엔트리)에 대하여 스캐닝될 수 있다. 가능한 무효 엔트리들 중에서, 사용할 엔트리를 선택하기 위해 다양한 방법들이 사용될 수 있다. 예를 들면, 랜덤 무효 엔트리(random invalid entry)가 선택될 수 있다. 대안적으로, 무효 엔트리는 트렌딩 표 내의 모든 빈 엔트리들이 연속적인 순서로 유지되도록 선택될 수 있다. 어떠한 무효 엔트리도 존재하지 않으면, 과도(T) 상태에서 가장 오래된 엔트리(또는 랜덤 엔트리)가 새로 개시된 애플리케이션을 추적하기 위해 선택될 수 있다. 어떠한 I 또는 T 상태 엔트리들도 존재하지 않는다면, 가장 오래된 신규(N) 상태 엔트리가 새로 보고된 속성 이벤트를 추적하기 위해 선택될 수 있다.

단계(804)에서, 트렌딩 표 엔트리가 선택되면, 새로 보고된 속성 이벤트를 추적하기 위한 선택된 엔트리의 STATE 필드는 신규(N)로 설정될 수 있고, ATTID는 새로 보고된 속성의 속성 값으로 설정될 수 있고, LLT 필드는 현재 시간(t)(예를 들어, 벽시계 시간)으로 설정될 수 있으며, ILC 및 C 필드들은 미리정의된 최소 값들(ILC_MIN(예를 들어, 1분) 및 C_MIN(예를 들어, 0))로 설정된다.

단계(806)에서, 시간(t')에서 동일한 속성 이벤트의 다음 보고 시에, 속성에 대한 표 내의 엔트리는 그것이 여전히 존재하고 축출되지 않았다면 발견된다(예를 들면, 다른 속성을 추적하기 위해 선택됨). 엔트리의 STATE는 과도(T)로 설정되고, ILC는 LLT와 현재 시스템 시간 사이의 차이(예를 들어, t'-t 또는 t'-LLT)로 설정되며, C 필드는 증분된다(예를 들어, 미리정의된 값 C_DELTA만큼). 대안적으로, ILC 필드는 그것의 오래된 그리고 신규 값들의 어떤 다른 함수, 예를 들어 이동 평균(running average)으로 설정될 수 있다.

단계(808)에서, 시간(t'')에서 동일한 속성 이벤트의 다음 보고 시에, 속성에 대한 표 내의 엔트리는 그것이 여전히 존재하고 축출되지 않았다면 발견된다(예를 들면, 다른 속성을 추적하기 위해 선택됨). 엔트리의 STATE는 계속 과도(T)로 설정될 수 있고, ILC는 LLT와 현재 (예를 들어, 벽) 시계 시간 사이의 차이(예를 들어, t"-t' 또는 t"-LLT)로 설정되며, C 필드는 다시 증분된다(예를 들어, 미리정의된 값 C_DELTA만큼).

단계(810)에서, 속성 이벤트의 여러 보고들 후에, 트렌딩 표 엔트리의 C 값이 임계값(예를 들어, C_HIGHTHRESHOLD)에 도달(예를 들어, 동일)하면, 단계(811)에서, 속성 엔트리의 상태는 STATE = A로 변경될 수 있다. 단계(810)에서, 트렌딩 표 엔트리의 C 값이 임계값(예를 들어, C_HIGHTHRESHOLD)에 도달하지 않는다면, 엔트리의 값들은 단계(808)에 따라 업데이트될 수 있다.

상태 "A"에 있는 동안 속성 이벤트가 보고될 때는 언제든지, 마지막 보고와 현재 보고의 시간 사이의 시간이 소정 시간의 양 내에 있으면(예를 들어, ILC_EPSILON = 5분), 속성 엔트리의 신뢰성(C) 필드는 그것이 미리정의된 최대 값(예를 들어, C_MAX)에 도달할 때까지 증분된다. 트렌딩 표 내의 속성 엔트리가 활성(A) 상태에 있는 경우, 엔트리의 ILC 값은 개시의 레이트(예를 들어, 카덴스)의 추정으로서 사용될 수 있고 엔트리의 ATTID는 트렌딩 속성 값을 식별하는 데 사용될 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 속성 값(ATTID) 및 카덴스 값(ILC)을 클라이언트에 송신하여, 클라이언트가 속성 값과 연관된 다음 이벤트를 예상하여 어떤 동작 또는 기능을 수행하도록 할 수 있다. 예를 들어, 속성 값 및 카덴스 값은 애플리케이션 관리자(106)에 송신되어, 애플리케이션 관리자(106)가 애플리케이션의 사용자 호출을 예상하여 백그라운드에서 식별된 애플리케이션(예를 들어, ATTID, "bundleId" 속성 값)을 개시함으로써, 사용자가 애플리케이션을 개시하기 전에 애플리케이션이 업데이트된 콘텐츠를 수신할 수 있도록 할 수 있으며, 이는 전술한 바와 같다. 예를 들면, 애플리케이션 관리자(106)는, 사용자가 애플리케이션을 호출하는 것을 예상하여 애플리케이션 관리자(106)를 웨이크하여 애플리케이션을 개시할 카덴스 값에 기초하여 타이머를 시작할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 검출된 속성 트렌드에 기초하여 속성 이벤트의 예상된 다음 발생을 클라이언트들에게 통지할 수 있다. 예를 들어, 샘플링 데몬(102)은, 트렌딩 애플리케이션이 애플리케이션 관리자(106)에 의해 개시되어야 함을 나타내는 신호 또는 통지를 애플리케이션 관리자(106)에 송신할 수 있다. 애플리케이션 관리자(106)는 애플리케이션 식별자(예를 들어, "bundleId" 속성 값)를 샘플링 데몬(102)에 송신함으로써 애플리케이션에 대한 관심을 등록할 수 있다. 샘플링 데몬(102)은 (예를 들어, 보고된 "bundleId" 시작 이벤트들에 기초하여) 사용자 호출에 대한 애플리케이션을 모니터링하여 애플리케이션이 트렌딩한지를 결정할 수 있고, 이는 전술한 바와 같다. 애플리케이션이 트렌딩한 경우, 샘플링 데몬(102)은 전술한 바와 같이 호출의 카덴스를 결정하고, 카덴스에 기초하여 결정된 시간에 통지 또는 신호를 애플리케이션 관리자(106)에 송신할 수 있다. 예를 들면, 카덴스가 4분이면, 샘플링 데몬(102)은 3분마다(예를 들어, 이벤트의 다음 발생보다 소정 시간 기간 전에) 신호를 애플리케이션 관리자(106)에 송신하여 애플리케이션 관리자(106)로 하여금 애플리케이션을 개시하게 할 수 있다. 카덴스가 6분으로 변경되면, 샘플링 데몬(102)은 카덴스 변경을 검출하고 애플리케이션 관리자(106)가 언제 시그널링되는지를 조정할 수 있다. 예를 들면, 샘플링 데몬(102)은 3분마다 대신에 5분마다 애플리케이션을 개시하도록 애플리케이션 관리자(106)를 시그널링하여 감소된 카덴스에 대해 조정될 수 있다(예를 들어, 호출들 사이에 증가된 시간 기간).

임의의 이유(예를 들어, 신규 엔트리 추가, 기존의 엔트리 업데이트 등)에 대한 속성 트렌딩 표의 각 검사에서, 마지막 개시 이래로의 시간이 그것들의 ILC보다 ILC_EPSILON만큼 큰 STATE = T 또는 STATE = A 내의 모든 엔트리들은 그것들의 C 값들이 감소되게 할 것이다. 그 지점에서 C 값이 최소 임계값(예를 들어, C_LOWTHRESHOLD) 미만으로 떨어지는 임의의 엔트리는 강등된다. 엔트리는, 예를 들면, 상태 A 에서 상태 T로, 또는 상태 T에서 상태 I로 강등될 수 있다.

일부 구현들에서, 전술한 트렌드 검출 메커니즘은 애플리케이션 호출들 또는 개시들 보다는 트렌딩 이벤트들을 검출하는 데 사용될 수 있다. 예를 들면, 전술한 트렌드 검출 방법 및 트렌딩 표는 모바일 디바이스(100) 상에서의 임의의 반복되는 이벤트(예를 들어, 임의의 속성 이벤트)를 검출하고 추적하는 데 사용될 수 있다. 트렌딩 이벤트는 스크린 터치, 네트워크 연결, 애플리케이션 고장, 네트워크 침입의 발생 및/또는 샘플링 데몬(102)에 보고되거나 시그널링될 수 있는 임의의 다른 이벤트를 포함할 수 있다.

푸시 통지

도 9는 푸시 통지들을 모바일 디바이스(100)에 제공하기 위한 시스템을 예시하는 블록도(900)이다. 일부 구현들에서, 모바일 디바이스(100)는 푸시 통지들을 수신하도록 구성될 수 있다. 예를 들면, 푸시 통지는, 푸시 제공자(902)에 의해 시작되고 푸시 통지 서버(906)를 통해 모바일 디바이스(100) 상에서 실행되는 푸시 서비스 데몬(904)에 송신되는 메시지일 수 있다.

일부 구현들에서, 푸시 제공자(902)는 애플리케이션(908)에 의해 모바일 디바이스(100)의 사용자에게 보여지는 사용자 승인 요청을 통해 푸시 통지들을 모바일 디바이스(100)에 송신하기 위하여 승인을 수신할 수 있다. 예를 들면, 푸시 제공자(902)는 애플리케이션(908)을 생성(예를 들어, 프로그래밍, 개발)한 동일한 벤더에 의해 소유되고, 운영되고/되거나 유지될 수 있는 서버일 수 있다. 푸시 제공자(902)는, 애플리케이션(908)이 푸시 제공자(902)가 푸시 통지들을 모바일 디바이스(100)로 송신하라는 승인을 요청하는 사용자 인터페이스를 모바일 디바이스(100) 상에 보여주고 사용자가 푸시 통지들이 승인됨을 나타내는 경우, 사용자로부터 승인을 수신하여 푸시 통지들을 모바일 디바이스(100)(예를 들어, 푸시 서비스 데몬(904))에 송신할 수 있다. 예를 들면, 사용자는 애플리케이션(908)에 의해 보여지는 사용자 인터페이스 상의 버튼을 선택하여 푸시 통지들이 푸시 제공자(902) 및/또는 애플리케이션(908)에 대해 승인됨을 나타낼 수 있다. 이어서, 푸시 제공자(902)는 모바일 디바이스(100)를 식별하고 모바일 디바이스(100)에 푸시 통지들을 라우팅하는 데 사용될 수 있는 디바이스 토큰을 수신할 수 있다. 예를 들면, 푸시 통지 서버(906)는 푸시 통지를 갖는 디바이스 토큰을 수신하고, 디바이스 토큰을 사용하여 어느 모바일 디바이스(100)가 푸시 통지를 수신해야 하는지를 결정할 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 승인된 푸시 애플리케이션들을 식별하는 정보를 푸시 통지 서버(906)에 송신할 수 있다. 예를 들면, 모바일 디바이스(100)는 푸시 통지 필터들(914) 및 모바일 디바이스(100)에 대한 디바이스 토큰을 포함하는 메시지(926)를 푸시 통지 서버(906)에 송신할 수 있다. 푸시 통지 서버(906)는 푸시 통지 서버(906)에 의해 서비스되는 각 모바일 디바이스에 대해 푸시 필터들(914)에 대한 디바이스 토큰들(예를 들어, 모바일 디바이스(100)에 대한 식별자)의 매핑을 저장할 수 있다. 푸시 필터들(914)은 예를 들면, 모바일 디바이스(100) 상에서 푸시 통지들을 수신하도록 승인을 수신한 애플리케이션들을 식별하는 정보를 포함할 수 있다.

일부 구현들에서, 푸시 필터들(914)은 모바일 디바이스(100)의 사용자에 의해 승인되지 않은 애플리케이션들에 대한 푸시 통지들을 필터링(예를 들어, 송신을 방지)하기 위하여 푸시 통지 서버(906)에 의해 사용될 수 있다. 푸시 제공자(902)에 의해 푸시 통지 서버(906)로 송신된 각 푸시 통지는 푸시 제공자(902) 및 모바일 디바이스(100)(예를 들어, 디바이스 토큰)와 연관된 애플리케이션(908)을 식별하는 정보(예를 들어, 식별자)를 포함할 수 있다.

통지 서버(906)가 푸시 통지를 수신하는 경우, 통지 서버(906)는 모바일 디바이스 식별 정보(예를 들어, 디바이스 토큰)를 사용하여, 수신된 푸시 통지에 어느 푸시 필터들(914)을 적용할지를 결정할 수 있다. 통지 서버(906)는 푸시 통지 내의 애플리케이션 식별 정보를 식별된 모바일 디바이스에 대한 푸시 필터들(914)과 비교하여 푸시 제공자(902)와 연관되고 푸시 통지에서 식별된 애플리케이션이 푸시 필터(914)에서 식별되는지 여부를 결정할 수 있다. 푸시 통지와 연관된 애플리케이션은 푸시 필터들(914)에서 식별되면, 이어서 통지 서버(906)는 푸시 제공자(902)로부터 수신된 푸시 통지를 모바일 디바이스(100)에 전송할 수 있다. 푸시 통지에서 식별된 애플리케이션이 푸시 필터들(914)에서 식별되지 않으면, 이어서 통지 서버는 푸시 제공자(902)로부터 수신된 푸시 통지를 모바일 디바이스(100)에 전송하지 않을 것이고 푸시 통지를 삭제할 수 있다.

비웨이킹 푸시 통지

일부 구현들에서, 통지 서버(906)는 높은 우선순위 푸시 통지들 및 낮은 우선순위 푸시 통지들을 처리하도록 구성될 수 있다. 예를 들면, 푸시 제공자(902)는 높은 우선순위 푸시 통지(910) 및/또는 낮은 우선순위 푸시 통지(912)를 푸시 통지 서버(906)에 송신할 수 있다. 푸시 제공자(902)는 예를 들어, 푸시 통지 서버(906) 및 모바일 디바이스(100)에 송신된 푸시 통지 내에 포함된 데이터에서 푸시 통지의 우선순위를 특정함으로써 높은 우선순위 또는 낮은 우선순위로서 푸시 통지를 식별할 수 있다.

일부 구현들에서, 푸시 통지 서버(906)는 높은 우선순위 푸시 통지(910)와 상이하게 낮은 우선순위 푸시 통지(912)를 처리할 수 있다. 예를 들면, 푸시 통지 서버(906)는 높은 우선순위 푸시(910)에 포함된 애플리케이션 식별 정보를 푸시 필터들(914) 내의 승인된 애플리케이션 식별 정보와 비교하여 높은 우선순위 푸시 통지(910)가 모바일 디바이스(100)에 전송될 수 있는지 여부를 결정하도록 구성될 수 있다. 높은 우선순위 푸시 통지(910) 내의 애플리케이션 식별 정보가 푸시 필터들(914) 내의 승인된 애플리케이션 식별자와 매칭되면, 이어서 푸시 통지 서버(906)는 높은 우선순위 푸시 통지를 모바일 디바이스(100)에 전송할 수 있다. 높은 우선순위 푸시 통지(910) 내의 애플리케이션 식별 정보가 푸시 필터들(914) 내의 승인된 애플리케이션 식별자와 매칭되지 않으면, 이어서 푸시 통지 서버(906)는 높은 우선순위 푸시 통지를 모바일 디바이스(100)에 전송하지 않을 것이다.

일부 구현들에서, 푸시 통지 서버(906)는 낮은 우선순위 푸시 통지들의 전달을 지연시키도록 구성될 수 있다. 예를 들면, 모바일 디바이스(100)가 푸시 통지 서버(906)로부터 푸시 통지를 수신하는 경우, 푸시 통지의 수신은 모바일 디바이스(100)로 하여금 (예를 들면, 슬립 또는 저전력 상태에 있으면) 웨이크업하게 한다. 모바일 디바이스(100)가 웨이크하면, 모바일 디바이스(100)는 배터리를 소모하거나, 셀룰러 데이터를 사용하거나, 모바일 디바이스(100)로 하여금 뜨거워지게 하거나, 그렇지 않으면 모바일 디바이스(100)에 영향을 줄 수 있는 다양한 서브시스템들 및 프로세서들을 켤 것이다. 모바일 디바이스(100)로의 낮은 우선순위 푸시 통지들의 전달을 방지하거나 지연시킴으로써, 모바일 디바이스(100)는 예를 들면, 네트워크(예를 들어, 셀룰러 데이터) 및 시스템(예를 들어, 배터리) 리소스들을 보존할 수 있다.

일부 구현들에서, 푸시 통지 필터들(914)은 웨이크 리스트(916) 및 비웨이크 리스트(918)를 포함할 수 있다. 웨이크 리스트(916)는 낮은 우선순위 푸시 통지들이 모바일 디바이스(100)에 전달되어야 하는 애플리케이션을 식별할 수 있다. 일부 구현들에서, 애플리케이션이 모바일 디바이스(100)에서 푸시 통지들을 수신하도록 승인되는 경우, 애플리케이션 식별 정보는 디폴트로 웨이크 리스트(914)에 추가된다. 비웨이크 리스트(918)는 낮은 우선순위 푸시 통지들이 지연되어야 하는 승인된 애플리케이션들을 식별할 수 있다. 비웨이크 리스트(918)를 채우기 위한 그리고/또는 웨이크 리스트(916)와 비웨이크 리스트(918)를 조작하기 위한 특정 메커니즘은 푸시 통지 시작된 백그라운드 업데이트들을 설명할 때 이하에서 더 상세히 설명된다. 일부 구현들에서, 높은 우선순위 푸시 통지들은 푸시 통지 서버(906)에서 지연되지 않을 것이고, 높은 우선순위 푸시 통지에서 식별된 애플리케이션이 푸시 필터들(914)에서 식별되는 한(예를 들어, 웨이크 리스트(914) 및/또는 비웨이크 리스트(918)) 모바일 디바이스(100)에 전달될 것이다.

일부 구현들에서, 푸시 통지 서버(906)가 낮은 우선순위 푸시 통지(912)를 수신하는 경우, 푸시 통지 서버(906)는 낮은 우선순위 푸시 통지(912) 내의 애플리케이션 식별자를 웨이크 리스트(916) 및/또는 비웨이크 리스트(918)와 비교할 수 있다. 예를 들면, 낮은 우선순위 푸시 통지(912) 내의 애플리케이션 식별 정보가 웨이크 리스트(916) 내의 승인된 애플리케이션 식별자와 매칭되면, 낮은 우선순위 푸시 통지(912)는 통지 메시지(920)로 모바일 디바이스(100)에 전달될 것이다.

일부 구현들에서, 비웨이크 리스트(918)에서 식별된 애플리케이션들과 연관된 낮은 우선순위 푸시 통지들의 전달은 지연될 수 있다. 예를 들면, 낮은 우선순위 푸시 통지(912)에서 식별된 애플리케이션이 또한 비웨이크 리스트(918)에서 식별되면, 이어서 낮은 우선순위 푸시 통지(912)는 푸시 통지 데이터 저장소(922)에 저장될 수 있고 모바일 디바이스(100)에 즉시 전달되지 않을 수 있다. 일부 구현들에서, 푸시 통지(높은 우선순위 또는 낮은 우선순위)에 의해 식별된 모바일 디바이스(100)가 푸시 통지 서버(906)에 현재 연결되어 있지 않으면, 연결해제된 모바일 디바이스(100)에 대한 푸시 통지는 모바일 디바이스(100)로의 이후 전달을 위해 푸시 통지 데이터 저장소(922)에 저장될 수 있다.

일부 구현들에서, 푸시 데이터 저장소(922)에 저장된 푸시 통지들은, 저장된 푸시 통지와 연관된 애플리케이션 식별자가 비웨이크 리스트(918)로부터 웨이크 리스트(916)로 이동될 때까지 또는 네트워크 연결이 푸시 통지 서버(906)와 모바일 디바이스(100) 사이에 구축될 때까지, 푸시 데이터 저장소(922)에 남아있을 것이다. 예를 들면, 푸시 통지 서버(906)와 모바일 디바이스(100) 사이의 네트워크 연결은, 다른(높은 우선순위 또는 낮은 우선순위) 푸시 통지가 모바일 디바이스(100)에 전달되는 경우 또는 모바일 디바이스(100)가 다른 전송들(924)(예를 들어, 상태 메시지, 심장박동 메시지, 킵 얼라이브 메시지(keep alive message) 등)을 푸시 통지 서버(906)에 송신하는 경우, 구축될 수 있다. 예를 들면, 모바일 디바이스(100)는 모바일 디바이스(100)가 소정 기간(예를 들어, 5분) 동안 활성화될 것임을 나타내는 메시지(924)를 푸시 통지 서버(905)에 송신할 수 있고, 푸시 통지 서버(906)는 특정된 활성 기간 동안 모든 수신된 푸시 통지들을 모바일 디바이스(100)에 송신할 수 있다. 일부 구현들에서, 네트워크 연결이 모바일 디바이스(100)와 푸시 통지 서버(906) 사이에 구축되는 경우, 푸시 통지 저장소(922)에 저장된 모든 푸시 통지들은 모바일 디바이스(100)에 전달될 것이다. 예를 들면, 푸시 통지 데이터 저장소(922)에 저장된 푸시 통지들은 모바일 디바이스(100)와 푸시 통지 서버(906) 사이의 다른 전송들에 의해 생성된 연결들을 통해 전송될 수 있다.

일부 구현들에서, 모바일 디바이스(100)는 푸시 통지 서버(906)와의 2개의 상이한 통신 채널들을 구축할 수 있다. 예를 들면, 2개의 통신 채널들은 동시에 또는 상이한 시간에서 구축될 수 있다. 모바일 디바이스(100)는 예를 들면, 푸시 통지 서버(906)에 대한 셀룰러 데이터 연결 및/또는 Wi-Fi 연결을 가질 수 있다. 일부 구현들에서, 모바일 디바이스(100)는 각 통신 채널에 대하여 상이한 푸시 필터들(914)을 생성하고 푸시 통지 서버(906)에 전송할 수 있다. 예를 들면, 셀룰러 데이터 연결은 셀룰러 데이터 연결에 걸쳐 높은 우선순위 및 낮은 우선순위 푸시 통지들을 언제 송신할지를 결정하기 위한 제1 세트의 푸시 필터들(914)과 연관될 수 있다. Wi-Fi 데이터 연결은 Wi-Fi 데이터 연결에 걸쳐 높은 우선순위 및 낮은 우선순위 푸시 통지들을 언제 송신할지를 결정하기 위한 셀룰러 데이터 푸시 필터들과 동일하거나 상이한 제2 세트의 푸시 필터들(914)과 연관될 수 있다. 푸시 통지 서버(906)가 푸시 통지를 수신하는 경우, 푸시 통지 서버는 푸시 통지에서 식별된 애플리케이션을, 푸시 통지 서버(906)가 푸시 통지를 모바일 디바이스(100)에 전송하는 데 사용할 통신 채널(예를 들어, Wi-Fi, 셀룰러)에 대한 푸시 통지 필터들과 비교할 수 있다.

푸시 시작된 백그라운드 업데이트

일부 구현들에서, 모바일 디바이스(100)에 의한 푸시 통지들의 수신은 모바일 디바이스(100) 상에서 애플리케이션들의 백그라운드 업데이트를 트리거할 수 있다. 예를 들면, 모바일 디바이스(100)(예를 들어, 푸시 서비스 데몬(904))가 푸시 통지 서버(906)로부터 푸시 통지 메시지(920)를 수신하는 경우, 푸시 서비스 데몬(904)은 푸시 통지 메시지(920) 내의 애플리케이션 식별자를 모바일 디바이스(100) 상에 저장된 푸시 필터들(928)과 비교하여 푸시 통지 메시지(920)가 적절하게 전달되었거나 푸시 통지 서버(906)에 의해 필터링되었어야 했는지(예를 들어, 전달되지 않았음)를 결정할 수 있다. 예를 들면, 푸시 필터들(928), 웨이크 리스트(930) 및 비웨이크 리스트(932)는 각각 푸시 필터들(914), 웨이크 리스트(916) 및 비웨이크 리스트(918)에 대응할 수 있다. 일부 구현들에서, 푸시 서비스 데몬(904)이 푸시 통지 메시지(920)가 모바일 디바이스(100)에 전달되지 않았어야 함을 결정하면, 푸시 통지 메시지(902)는 삭제될 것이다.

낮은 우선순위 푸시 통지

일부 구현들에서, 모바일 디바이스(100)에 의해 수신된 푸시 통지 메시지(920)는 낮은 우선순위 푸시 통지를 포함할 수 있다. 예를 들면, 낮은 우선순위 푸시 통지는 콘텐츠 업데이트들이 푸시 통지와 연관된 애플리케이션에 이용 가능함을 나타낼 수 있다. 따라서, 낮은 우선순위 푸시 통지가 애플리케이션(908)의 개시를 야기하는 경우, 애플리케이션(908)은 하나 이상의 네트워크 리소스(예를 들어, 푸시 제공자(902))로부터 업데이트된 콘텐츠를 다운로드할 수 있다.

일부 구현들에서, 푸시 서비스 데몬(904)이 모바일 디바이스(100) 상의 애플리케이션(예를 들어, 애플리케이션(908))과 연관된 낮은 우선순위 푸시 통지를 수신하는 경우, 푸시 서비스 데몬(904)은 수신된 낮은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해도 좋은지 여부를 샘플링 데몬(102)에 질의할 수 있다. 예를 들면, 푸시 서비스 데몬(904)은 수신된 낮은 우선순위 푸시 통지와 연관된 애플리케이션에 대한 식별자(예를 들어, "bundleId" 속성 값)를 샘플링 데몬(102)에 송신함으로써 샘플링 데몬(102)이 승인 제어를 수행할 것을 요청할 수 있다. 샘플링 데몬(102)은 도 4를 참조하여 전술한 바와 같이, 데이터 예산들, 에너지 예산들, 속성 예산들 및 투표자 피드백을 체크함으로써 승인제어를 수행할 수 있다. 샘플링 데몬(102)은 승인 제어 프로세스의 결과에 기초하여 낮은 우선순위 푸시 통지에 의해 식별된 애플리케이션을 개시하는 것이 좋은지 여부를 나타내는 값을 푸시 서비스 데몬(904)으로 반환할 수 있다.

일부 구현들에서, 승인 제어 요청으로부터 반환된 값이 애플리케이션을 개시해도 좋다는 "예"를 나타내면, 푸시 서비스 데몬(904)은 애플리케이션 관리자(106)에 낮은 우선순위 푸시 통지를 송신할 것이고, 애플리케이션 관리자(106)는 애플리케이션(예를 들어, 애플리케이션(908))을 호출할 수 있다. 이어서, 애플리케이션(908)은 네트워크(예를 들어, 인터넷)를 통해 푸시 제공자(902)와 통신하여 푸시 제공자(902)로부터 업데이트된 콘텐츠를 수신할 수 있다.

일부 구현들에서, 승인 제어 요청으로부터 반환된 값이 애플리케이션을 개시해서는 안된다는 "아니오"를 나타내면, 푸시 서비스 데몬(904)은 푸시 통지 데이터 저장소(934)에 낮은 우선순위 푸시 통지를 저장할 것이다. 예를 들면, 낮은 우선순위 푸시 통지를 저장하는 경우, 푸시 서비스 데몬(904)은 푸시 통지에서 식별된 애플리케이션에 대해 수신된 마지막 푸시 통지만을 저장할 것이다.

일부 구현들에서, 샘플링 데몬(102)이 푸시 서비스 데몬(904)이 지금 당장 애플리케이션을 개시해서는 안됨을 나타내는 경우(예를 들어, 승인 제어 응답이 "아니오"임), 푸시 서비스 데몬(904)은 애플리케이션에 대한 애플리케이션 식별자를 웨이크 리스트(930)로부터 비웨이크 리스트(932)로 이동시킬 수 있다. 예를 들면, 샘플링 데몬(102)이 모바일 디바이스의 예산, 및/또는 상태가 애플리케이션을 개시하는 것을 허용하지 않음을 결정하면, 푸시 통지 서버(906)로 하여금 애플리케이션과 연관된 추가의 낮은 우선순위 푸시 통지들에 대해 모바일 디바이스(100)를 웨이크하게 하는 것은 단지 모바일 디바이스(100)의 데이터 및 에너지 예산들을 더 소비하거나 환경 조건들이 나빠지게 할 것이다(예를 들면, 디바이스가 뜨거워지게 함). 따라서, 애플리케이션 식별자를 비웨이크 리스트(932)로 이동시키고 업데이트된 필터들(928)(예를 들어, 웨이크 리스트(930) 및 비웨이크 리스트(932))을 포함하는 푸시 통지 서버(906)에 메시지(926)를 송신함으로써, 통지 서버(906)는 그 자신의 푸시 필터들(914), 웨이크 리스트(916) 및 비웨이크 리스트(918)를 업데이트하여 변경들을 푸시 필터들(928)에 반영하고, 애플리케이션에 대한 추가의 낮은 우선순위 푸시 통지들이 모바일 디바이스(100)에 전달되는 것을 방지할 수 있다.

일부 구현들에서, 승인 제어 요청으로부터 반환된 값이 애플리케이션을 개시해서는 "절대 안됨"을 나타내면, 푸시 서비스 데몬(904)은 낮은 우선순위 푸시 통지를 삭제하고 푸시 필터들(928)로부터 푸시 통지와 연관된 애플리케이션 식별자를 제거할 것이다. 업데이트된 푸시 필터들은 푸시 통지 서버(906)에 송신될 수 있고, 푸시 통지 서버(906) 상의 푸시 필터들(914)은 푸시 통지 서버(906)가 더이상 애플리케이션 식별자와 연관된 푸시 통지들을 송신하는 것을 방지하도록 업데이트될 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 푸시 서비스 데몬(904)에 "중지" 신호를 송신하여 향후 낮은 우선순위 푸시 통지들이 푸시 통지 서버(906)로부터 모바일 디바이스(100)로 송신되는 것을 일시적으로 방지할 수 있다. 예를 들면, 샘플링 데몬(102)은, 데이터 예산이 현재 시간에 대해 고갈되고, 에너지 예산이 현재 시간에 대해 고갈되고, 시스템이 열 이벤트(예를 들어, 모바일 디바이스(100)가 너무 뜨거움)를 경험하고 있고, 모바일 디바이스(100)가 품질이 나쁜 셀룰러 연결을 갖고 모바일 디바이스(100)가 Wi-Fi에 연결되지 않고/않거나 모바일 디바이스(100)가 음성 호에 연결되고 Wi-Fi에 연결되어 있지 않음을 샘플링 데몬(102)이 결정하는 경우, 중지 신호를 푸시 서비스 데몬(904)에 송신할 수 있다. 푸시 서비스 데몬(904)이 중지 신호를 수신하는 경우, 푸시 서비스 데몬(904)은 웨이크 리스트(930) 내의 애플리케이션 식별자들을 비웨이크 리스트(932)로 이동시키고, 업데이트된 푸시 필터들(928)을 푸시 통지 서버(906)에 전송하여 푸시 필터들(914)을 업데이트할 수 있다. 따라서, 푸시 통지 서버(906)는 향후 낮은 우선순위 푸시 통지들이 모바일 디바이스(100)를 웨이크하고 모바일 디바이스(100)의 예산들, 제한들 및 동작 상태들에 영향을 주는 것을 일시적으로 방지할 것이다.

일부 구현들에서, 샘플링 데몬(102)은 재시도 신호를 푸시 서비스 데몬(904)에 전송할 수 있다. 예를 들면, 샘플링 데몬(102)은 예산들, 네트워크 연결들, 제한들 및 디바이스 상태들의 상태를 모니터링할 수 있고, 푸시 데이터 예산이 고갈되지 않은 경우, 에너지 예산이 고갈되지 않은 경우, 모바일 디바이스(100)가 열 이벤트를 경험하고 있지 않는 경우, 모바일 디바이스(100)가 양호한 품질의 셀룰러 연결을 갖거나 Wi-Fi에 연결된 경우, 모바일 디바이스(100)가 음성 호에 연결되지 않은 경우, 그리고 개시 레이트 제한들이 리셋된 경우 재시도 메시지를 푸시 서비스 데몬(904)에 송신할 것이다. 푸시 서비스 데몬(904)이 재시도 신호를 수신하면, 푸시 서비스 데몬(904)은 푸시 통지 데이터 저장소(934) 내의 각 푸시 통지에 대한 승인 제어 요청을 샘플링 데몬(102)에 송신하여 저장된 푸시 통지들과 연관된 각 애플리케이션(예를 들어, "bundleId" 속성 값)을 개시해도 좋은지 여부를 결정할 것이다.

샘플링 데몬(102)이 승인 제어 요청으로부터 "예"를 반환하면, 푸시 서비스 데몬(904)은 푸시 통지를 애플리케이션 관리자(106)에 송신할 수 있고, 애플리케이션 관리자(106)는 푸시 통지와 연관된 애플리케이션을 모바일 디바이스(100) 상에서 백그라운드 프로세스로서 개시할 수 있으며, 이는 전술한 바와 같다. 애플리케이션이 개시되면, 애플리케이션은 콘텐츠 또는 데이터 업데이트들을 다운로드하고 다운로드된 데이터에 기초하여 애플리케이션들 사용자 인터페이스들을 업데이트할 수 있다. 애플리케이션 관리자(106)는 낮은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해도 좋은지 여부를 샘플링 데몬(102)에 질의하지 않을 것이다.

높은 우선순위 푸시 통지

일부 구현들에서, 모바일 디바이스(100)에 의해 수신된 푸시 통지 메시지(920)는 높은 우선순위 푸시 통지를 포함할 수 있다. 예를 들면, 높은 우선순위 푸시 통지는 콘텐츠 업데이트들이 푸시 통지와 연관된 애플리케이션에 이용 가능함을 나타낼 수 있다. 따라서, 높은 우선순위 푸시 통지가 애플리케이션의 호출을 야기하는 경우, 애플리케이션은 하나 이상의 네트워크 리소스로부터 업데이트된 콘텐츠를 다운로드할 수 있다. 일부 구현들에서, 높은 우선순위 푸시 통지가 푸시 서비스 데몬(904)에 의해 수신되는 경우, 푸시 서비스 데몬(904)은 샘플링 데몬(102)에 승인 제어 요청을 하지 않으면서 높은 우선순위 푸시 통지를 애플리케이션 관리자(106)에 송신할 것이다.

일부 구현들에서, 애플리케이션 관리자(106)가 애플리케이션과 연관된 푸시 통지를 수신하는 경우, 애플리케이션 관리자(106)는 샘플링 데몬(102)에 승인 제어 요청을 할 것이다. 승인 제어 요청에 응답하여, 샘플링 데몬(102)은 전술한 바와 같이 "예", "아니오" 또는 "절대 안됨" 응답들로 응답할 수 있다. 애플리케이션 관리자(106)가 승인 제어 요청에 대해 "예" 응답을 수신하는 경우, 애플리케이션 관리자(106)는 수신된 높은 우선순위 푸시 통지와 연관된 애플리케이션을 모바일 디바이스(100) 상에서 백그라운드 프로세스로서 개시할 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)가 승인 제어 요청에 대해 "아니오" 응답을 수신하는 경우, 애플리케이션 관리자(106)는 높은 우선순위 푸시 통지 저장소(936)에 높은 우선순위 푸시 통지를 저장할 수 있다. 애플리케이션 관리자(106)가 "절대 안됨" 응답을 수신하는 경우, 애플리케이션 관리자(106)는 높은 우선순위 푸시 통지를 삭제하고 푸시 통지와 연관된 애플리케이션에 대한 푸시 통지 데이터 저장소(936)에 저장된 임의의 푸시 통지들을 삭제할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 "재시도 승인" 신호를 애플리케이션 관리자(106)에 송신할 수 있다. 예를 들면, 애플리케이션 관리자(106)가 샘플링 데몬(102)으로부터 "재시도 승인" 메시지를 수신하는 경우, 애플리케이션 관리자(106)는 높은 우선순위 푸시 통지 데이터 저장소(936)에서 각각의 높은 우선순위 푸시 통지와 연관된 애플리케이션들에 대한 승인 제어 요청을 하고 승인 제어 요청에 응답하여 "예" 응답이 수신되는 경우 각각의 애플리케이션들을 백그라운드 프로세스들로서 개시할 수 있다.

푸시 통지의 표시를 지연시킴

일부 구현들에서, 높은 우선순위 푸시 통지들은 그래픽 사용자 인터페이스가 모바일 디바이스(100) 상에 표시되게 할 수 있다. 예를 들면, 높은 우선순위 푸시 통지의 수신은, 배너, 풍선 또는 다른 그래픽 객체가 모바일 디바이스(100)의 그래픽 사용자 인터페이스 상에 표시되게 할 수 있다. 그래픽 객체는 예를 들면, 수신된 푸시 통지의 주제 또는 콘텐츠를 나타내는 정보를 포함할 수 있다.

일부 구현들에서, 애플리케이션 관리자(106)가 높은 우선순위 푸시 통지를 수신하는 경우, 애플리케이션 관리자(106)는 통지가 모바일 디바이스(100)의 그래픽 사용자 인터페이스 상에 표시되게 할 수 있다. 그러나, 높은 우선순위 푸시 통지가 높은 우선순위 푸시 통지와 연관된 애플리케이션에 다운로드될 데이터 업데이트들이 있음을 나타내는 경우, 애플리케이션은 푸시 통지가 표시되기 전에 모바일 디바이스(100)의 백그라운드에서 개시될 수 있다. 예를 들면, 애플리케이션 관리자(106)는 높은 우선순위 푸시 통지와 연관된 애플리케이션을 개시하는 것과 사용자에게 푸시 통지를 알리는 그래픽 객체(예를 들어, 배너)를 표시하는 것 사이에 지연되는 시간의 양(예를 들어, 30 초)으로 구성될 수 있다. 지연은 예를 들면, 사용자에 의해 호출되기 전에 콘텐츠 업데이트들을 다운로드하고 애플리케이션의 사용자 인터페이스들을 업데이트하기에 충분한 시간을 애플리케이션에 허용할 수 있다. 따라서, 사용자가 그래픽 객체에 입력을 제공하거나 그렇지 않으면 높은 우선순위 푸시 통지와 연관된 애플리케이션을 호출하는 경우, 애플리케이션의 사용자 인터페이스들은 최신일 것이고, 사용자는 애플리케이션에 대한 업데이트들을 기다리도록 강요받지 않을 것이다. 일부 구현들에서, 애플리케이션 관리자(106)가 높은 우선순위 푸시 통지와 연관된 애플리케이션을 개시할 수 없으면, 모바일 디바이스(100)는 그래픽 객체(예를 들어, 배너)를 표시하여 높은 우선순위 푸시 통지가 수신되었음을 사용자에게 통지할 것이다.

예시적인 푸시 통지 프로세스

도 10은 푸시 통지 서버(906)에서 비웨이킹 푸시들을 수행하기 위한 예시적인 프로세스(1000)의 흐름도이다. 단계(1002)에서, 푸시 통지 서버(906)는 푸시 통지를 수신할 수 있다. 예를 들면, 푸시 통지 서버(906)는 푸시 통지 제공자(902)(예를 들어, 애플리케이션 벤더에 의해 운영되는 서버)로부터 푸시 통지를 수신할 수 있다.

단계(1004)에서, 푸시 통지 서버(906)는 푸시 통지가 낮은 우선순위 푸시 통지임을 결정할 수 있다. 예를 들면, 푸시 통지 제공자는 푸시 통지의 우선순위를 특정하는 푸시 통시 내의 데이터를 포함할 수 있다. 푸시 통지 서버(906)는 푸시 통지의 콘텐츠를 분석하여 푸시 통지의 우선순위를 결정할 수 있다.

단계(1006)에서, 푸시 통지 서버(906)는 푸시 통지를 푸시 통지 필터와 비교할 수 있다. 예를 들면, 푸시 통지는 낮은 우선순위 푸시 통지가 지향되는 모바일 디바이스(100) 상에 설치되거나 구성된 애플리케이션을 식별할 수 있다. 푸시 통지는 예를 들면, 애플리케이션 식별자(예를 들어, "bundleId" 속성 값)를 포함할 수 있다. 푸시 통지 서버(906)는 푸시 통지 내의 애플리케이션 식별자를 푸시 통지 필터의 비웨이크 리스트(918) 내의 애플리케이션 식별자들과 비교할 수 있다.

단계(1008)에서, 푸시 통지 서버(906)는 낮은 우선순위 푸시 통지가 저장되어야 함을 결정할 수 있다. 예를 들면, 낮은 우선순위 푸시 통지로부터의 애플리케이션 식별자가 푸시 통지 필터의 비웨이크 리스트(918)에 있으면, 푸시 통지 서버(906)는 낮은 우선순위 푸시가 푸시 통지 데이터 저장소(922) 내에 저장되어야 함을 결정할 수 있다.

단계(1010)에서, 단계(1008)에서의 결정에 기초하여, 낮은 우선순위 푸시 통지는 푸시 통지 서버(906)의 데이터베이스 또는 데이터 저장소(922)에 저장되고 모바일 디바이스(100)에 즉시 송신되지 않을 것이다.

단계(1012)에서, 푸시 통지 서버(906)는 모바일 디바이스(100)에 대한 네트워크 연결이 구축되었음을 결정할 수 있다. 예를 들면, 푸시 통지 서버(906)는 모바일 디바이스(100)에 대해 네트워크 연결을 생성하여 다른 높은 우선순위 푸시 또는 낮은 우선순위 푸시를 전달할 수 있다. 모바일 디바이스(100)는 푸시 통지 서버(906)에 대해 네트워크 연결을 구축하여 통지 필터 변화, 주기적 상태 업데이트, 킵 얼라이브 메시지 또는 다른 메시지들을 푸시 통지 서버(906)에 송신할 수 있다.

단계(1014)에서, 푸시 통지 서버(906)는 모바일 디바이스(100)에 대한 네트워크 연결이 구축되었음을 결정하는 것에 응답하여 저장된 푸시 통지들을 송신할 수 있다. 예를 들면, 푸시 통지 서버(906)는 푸시 통지 서버(906)에 저장된 낮은 우선순위 푸시 통지들을 모바일 디바이스(100)에 송신할 수 있다.

도 11은 낮은 우선순위 푸시 통지에 응답하여 애플리케이션의 백그라운드 업데이트를 수행하기 위한 예시적인 프로세스(1100)의 흐름도이다. 단계(1102)에서, 모바일 디바이스(100)는 푸시 통지 서버(906)로부터 낮은 우선순위 푸시 통지를 수신할 수 있다.

단계(1104)에서, 모바일 디바이스(100)는 낮은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 예를 들면, 애플리케이션은 모바일 디바이스(100) 상에서 백그라운드 프로세스로서 개시될 수 있다. 모바일 디바이스(100)는 전술한 승인 제어 프로세스를 사용하여 애플리케이션을 개시하는 것이 좋은지 여부를 결정할 수 있다. 예를 들어, 모바일 디바이스(100)(예를 들어, 샘플링 데몬(102))는 모바일 디바이스(100)에 대하여 결정된 데이터, 에너지 및/또는 속성 예산들에 기초하여 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 모바일 디바이스(100)는 다양한 투표자들로부터의 응답들에 기초한 모바일 디바이스의 상태들 및/또는 모바일 디바이스의 네트워크 연결들의 상태에 기초하여 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 애플리케이션을 개시해도 좋은지 여부(예를 들어, 승인 제어)를 결정하기 위한 상세 사항들은 도 4를 참조하여 위에서 더 상세하게 설명되었다.

단계(1106)에서, 모바일 디바이스(100)는 디바이스 상태들, 예산들, 제한들 및 다른 데이터가 애플리케이션을 개시해서는 안된다는 것을 나타내는 경우 낮은 우선순위 푸시 통지를 저장할 수 있다. 예를 들면, 모바일 디바이스(100)는 낮은 우선순위 푸시 통지들을 데이터베이스 또는 모바일 디바이스(100) 상의 다른 데이터 저장소에 저장할 수 있다.

단계(1108)에서, 모바일 디바이스(100)는 백그라운드 애플리케이션을 개시해서는 안된다는 것을 결정하는 것에 응답하여 그것의 푸시 통지 필터들을 업데이트할 수 있다. 예를 들면, 모바일 디바이스(100)는 낮은 우선순위 푸시 통지와 연관된 애플리케이션을 모바일 디바이스(100) 상의 푸시 통지 필터들의 비웨이크 리스트로 이동시킬 수 있다.

단계(1110)에서, 모바일 디바이스(100)는 업데이트된 통지 필터들을 푸시 통지 서버(906)에 전송할 수 있다. 푸시 통지 서버(906)는 모바일 디바이스(100)로부터 수신된 필터들에 기초한 그 자신의 푸시 통지 필터들을 업데이트하여, 낮은 우선순위 푸시 통지들을 모바일 디바이스(100)에 언제 전송하고 언제 전송하지 않는지를 결정할 수 있다.

단계(1112)에서, 모바일 디바이스(100)는 낮은 우선순위 푸시 통지들과 연관된 애플리케이션을 개시하는 것을 재시도해도 좋음을 결정할 수 있다. 예를 들면, 모바일 디바이스(100)는, 전술한 바와 같이, 예산들, 제한들 및 디바이스 상태들이, 모바일 디바이스(100) 상에서 추가의 백그라운드 애플리케이션들을 개시하는 것을 허용함을 결정할 수 있다.

단계(1114)에서, 모바일 디바이스(100)는 저장된 낮은 우선순위 푸시 통지와 연관된 특정 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 예를 들면, 모바일 디바이스(100)의 샘플링 데몬(102)은 모바일 디바이스(100) 상에 구성된 예산들이 현재 시간에 대해 리셋되거나 보충되었음을, 그리고 모바일 디바이스(100)의 환경 조건 및 네트워크 연결들이 특정 백그라운드 애플리케이션을 개시하기에 충분히 양호함을 결정할 수 있다.

단계(1116)에서, 모바일 디바이스(100)는 모바일 디바이스(100)가 애플리케이션을 개시해도 좋음을 결정하는 경우 특정 애플리케이션을 개시할 수 있다. 예를 들면, 특정 애플리케이션은 백그라운드 프로세스로서 개시되어, 사용자가 애플리케이션을 호출하기 전에 신규 콘텐츠를 다운로드하고 애플리케이션의 사용자 인터페이스들을 업데이트할 수 있다. 이러한 프로세스는 사용자로 하여금 애플리케이션을 호출하게 하고, 다운로드될 콘텐츠 업데이트들 그리고 리프레시될 애플리케이션의 사용자 인터페이스들을 기다리지 않아도 되게 할 것이다.

도 12는 높은 우선순위 푸시 통지에 응답하여 애플리케이션의 백그라운드 업데이트를 수행하기 위한 예시적인 프로세스(1200)의 흐름도이다. 단계(1202)에서, 모바일 디바이스(100)는 높은 우선순위 푸시 통지를 수신할 수 있다.

단계(1204)에서, 모바일 디바이스(100)는 높은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 예를 들면, 모바일 디바이스(100)의 샘플링 데몬(102)은 모바일 디바이스(100)의 예산들 및 환경 조건들(예를 들어, 디바이스 상태, 네트워크 상태 등)에 기초하여 애플리케이션을 개시해도 좋은지 여부를 결정하기 위해 승인 제어를 수행할 수 있다.

단계(1206)에서, 모바일 디바이스(100)는, 높은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해서는 안되는 경우(예를 들어, 승인 제어가 "아니오"를 반환) 높은 우선순위 푸시 통지를 저장할 수 있다. 예를 들면, 모바일 디바이스(100)는 데이터베이스, 큐(queue), 또는 다른 적절한 데이터 구조물에 높은 우선순위 푸시 통지를 저장할 수 있다.

단계(1208)에서, 모바일 디바이스(100)는 저장된 높은 우선순위 푸시 통지들과 연관된 애플리케이션들을 개시하는 것을 재시도해도 좋음을 결정할 수 있다. 예를 들면, 모바일 디바이스(100)는, 상기 승인 제어 설명에서 논의된 바와 같이, 데이터, 에너지 및/또는 속성 예산들이 보충되었거나, 디바이스 상태들이 개선되었거나, 네트워크 상태들이 개선되었거나, 또는 모바일 디바이스(100)의 다른 상태들이 변경된 경우, 애플리케이션들을 개시하는 것을 재시도해도 좋음을 결정할 수 있다.

단계(1210)에서, 모바일 디바이스(100)는 저장된 높은 우선순위 푸시 통지와 연관된 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다. 예를 들면, 모바일 디바이스(100)는 상기 논의된 기준들에 기초하여 애플리케이션을 개시해도 좋은지 여부를 결정할 수 있다.

단계(1212)에서, 모바일 디바이스(100)는 모바일 디바이스(100) 상의 백그라운드에서 애플리케이션을 개시할 수 있다. 예를 들면, 애플리케이션은 애플리케이션이 네트워크(예를 들어, 인터넷) 상에서 네트워크 리소스(예를 들어, 콘텐츠 서버)로부터 업데이트된 콘텐츠를 다운로드할 수 있도록 모바일 디바이스(100) 상에서 백그라운드 프로세스로서 개시될 수 있다.

단계(1214)에서, 모바일 디바이스(100)는 사용자에게 푸시 통지를 보여주기 전에 일정 기간을 기다릴 수 있다. 예를 들면, 모바일 디바이스는 수신된 높은 우선순위 푸시 통지를 사용자에게 통지하기 전에 애플리케이션이 일정 기간 동안 콘텐츠를 다운로드하게 하도록 구성될 수 있다.

단계(1216)에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 사용자 인터페이스 상에 푸시 통지를 보여줄 수 있다. 예를 들면, 모바일 디바이스(100)는 높은 우선순위 푸시 통지를 설명하는 정보를 포함하는 그래픽 객체(예를 들어, 배너)를 보여줄 수 있다. 사용자는 예를 들면, 그래픽 객체를 선택하여 애플리케이션을 호출할 수 있다. 사용자에게 통지가 보여지기 전에 애플리케이션은 콘텐츠를 다운로드할 시간이 있었으므로, 사용자가 애플리케이션을 호출하는 경우, 애플리케이션은 사용자로 하여금 업데이트된 콘텐츠가 네트워크로부터 다운로드되기를 기다리도록 강요하지 않으면서 업데이트된 콘텐츠를 사용자에게 표시할 수 있을 것이다.

백그라운드 업로드/다운로드

도 13은 모바일 디바이스(100) 상에서 데이터의 백그라운드 다운로드 및/또는 업로드를 수행하기 위한 예시적인 시스템(1300)의 블록도이다. 백그라운드 다운로드 및/또는 업로드는 사용자로부터의 명백한 입력 없이 애플리케이션에 의해 시작되는 네트워크 데이터 전송일 수 있다. 예를 들면, 백그라운드 다운로드는 사용자가 비디오 게임 애플리케이션을 재생하는 동안 비디오 게임의 다음 레벨을 검색하기 위해 수행될 수 있다. 반대로, 포그라운드 다운로드 또는 업로드는, 다운로드 또는 업로드가 발생해야 한다는 사용자로부터의 명백한 지시에 응답하여 수행되는 네트워크 데이터 전송일 수 있다. 예를 들면, 포그라운드 다운로드는 그림, 영화 또는 문서를 다운로드하기 위해 웹페이지 링크를 선택하는 사용자에 의해 시작될 수 있다. 유사하게는, 백그라운드 업로드들은 네트워크 리소스(예를 들어, 서버)에 데이터를 업로드하라는 명백한 사용자 요청이 사용자로부터 수신되었는지 여부에 기초하여 포그라운드 업로드들과 구별될 수 있다.

일부 구현들에서, 포그라운드 다운로드/업로드(예를 들어, 사용자에 의해 명백히 요청된 다운로드/업로드)는 사용자를 위해 즉시 수행된다. 예를 들면, 사용자 요청된 다운로드/업로드는 즉시 수행되고 제약들을 예산책정하는 것 또는 다른 고려의 대상이 아니다. 포그라운드 다운로드/업로드는 셀룰러 데이터 연결을 통해 수행될 수 있다. 반대로, 백그라운드 다운로드 및/또는 업로드는 기회주의적으로 그리고 제약들을 예산책정하는 것 및 모바일 디바이스(100)의 온도와 같은 환경 조건들을 고려하는 것 내에서 수행될 수 있다. 예를 들어, 속성이 전술한 승인 제어 메커니즘에 의해 승인되는 경우, 속성 또는 속성 값에 대해 백그라운드 다운로드 또는 업로드가 수행될 수 있다. 일부 구현들에서, 백그라운드 다운로드 및/또는 업로드는 Wi-Fi 네트워크 연결들로 제한될 수 있다.

일부 구현들에서, 시스템(1300)은 백그라운드 전송 데몬(1302)을 포함할 수 있다. 일부 구현들에서, 백그라운드 전송 데몬(1302)은 모바일 디바이스(100) 상에서 실행되는 애플리케이션들 또는 프로세스들 대신에 데이터 또는 콘텐츠의 백그라운드 다운로드 및 업로드를 수행하도록 구성될 수 있다. 예를 들면, 백그라운드 전송 데몬(1302)은 애플리케이션(1304) 대신에 애플리케이션(1304)과 서버(1306) 사이에서 백그라운드 다운로드 및/또는 업로드를 수행할 수 있다. 따라서, 백그라운드 다운로드/업로드는 애플리케이션(1304)으로부터의 프로세스를 벗어나 수행될 수 있다(예를 들면, 다운로드/업로드를 요청하는 프로세스에서/에 의해 수행되지 않음).

일부 구현들에서, 애플리케이션(1304)은 백그라운드 전송 데몬(1304)에 요청을 송신함으로써 백그라운드 다운로드/업로드를 시작하여 데이터를 다운로드하거나 업로드할 수 있다. 예를 들면, 데이터(예를 들어, 콘텐츠)를 다운로드하기 위한 요청은, 그것으로부터 데이터가 다운로드될 수 있는 네트워크 위치를 식별할 수 있다. 데이터를 업로드하기 위한 요청은 데이터가 업로드될 수 있는 네트워크 위치 및 데이터가 모바일 디바이스(100) 상에서 현재 저장되어 있는 위치를 식별할 수 있다. 요청은 또한 애플리케이션(1304)을 식별할 수 있다. 요청이 이루어지면, 애플리케이션(1304)은, 애플리케이션이 모바일 디바이스(100) 상에서 컴퓨팅 및/또는 네트워크 리소스들을 계속해서 소비하지 않으면서 백그라운드 다운로드/업로드가 백그라운드 전송 데몬(1304)에 의해 수행되도록, 셧다운되거나 보류될 수 있다.

일부 구현들에서, 데이터의 백그라운드 업로드 또는 다운로드를 수행하기 위한 요청을 수신하면, 백그라운드 전송 데몬(1302)은 네트워크를 통해 백그라운드 전송 데몬(1302)이 데이터 전송을 수행해도 좋은지 여부를 결정하기 위한 요청을 샘플링 데몬(102)에 송신할 수 있다. 예를 들어, 백그라운드 전송 데몬(1302)은 샘플링 데몬(102)이 데이터 전송을 대한 승인 제어를 수행할 것을 요청할 수 있다. 승인 제어 요청에서, 백그라운드 전송 데몬(1302)은 백그라운드 전송 데몬(1302)에 대한 식별자(예를 들어, "bundleId" 속성 값) 또는 백그라운드 전송을 요청하는 애플리케이션에 대한 식별자를 제공하여 승인 제어가 백그라운드 전송 데몬 또는 애플리케이션 상에서 수행되도록 할 수 있다. 승인 제어 요청은 시스템-범위 데이터 예산으로부터 공제될 요청의 비용으로서 전송될 데이터의 양을 포함될 수 있다.

백그라운드 전송 데몬(1302)으로부터 승인 제어 요청을 수신하는 것에 응답하여, 샘플링 데몬(102)은 시스템-범위 데이터 및/또는 에너지 예산들이 현재 시간에 대해 고갈되었는지 여부를 결정할 수 있다. 일부 구현들에서, 샘플링 데몬(102)이 모바일 디바이스(100)가 외부 전력원에 연결되어 있음을 결정하면, 샘플링 데몬(102)은 에너지 예산에 기초하여 백그라운드 다운로드/업로드를 방지하지 않을 것이다. 샘플링 데몬(102)은 모바일 디바이스(100)가 Wi-Fi에 연결되었는지 여부를 결정할 수 있다. 샘플링 데몬(102)은 또한 모바일 디바이스(100)가 열 이벤트(예를 들어, 미리정의된 임계값 초과의 동작 온도) 중에 있는지 여부를 결정할 수 있다. 일부 구현들에서, 샘플링 데몬(102)이 데이터 예산이 고갈되고 모바일 디바이스(100)가 Wi-Fi에 연결되지 않음을, 에너지 예산이 고갈되고 모바일 디바이스(100)가 외부 전력원에 연결되지 않음을, 또는 모바일 디바이스(100)가 열 이벤트 중에 있음을 결정하면, 이어서 샘플링 데몬(102)은 백그라운드 전송 데몬(1302)에 의한 승인 제어 요청에 대하여 "아니오" 응답을 반환할 것이다.

일부 구현들에서, 백그라운드 전송 데몬(1302)이 샘플링 데몬(102)으로부터 승인 제어 요청에 대해 "아니오" 응답을 수신하는 경우, 프로세스(1302)는 애플리케이션(1304)으로부터의 백그라운드 다운로드/업로드 요청을 요청 저장소(1308)에 저장할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 재시도 신호를 백그라운드 전송 데몬(1302)에 송신할 수 있다. 예를 들면, 샘플링 데몬(102)은, 데이터 및 에너지 예산들이 보충되는 경우 그리고 시스템이 더이상 열 이벤트를 경험하고 있지 않는 경우, 백그라운드 전송 데몬(1302)에 재시도 신호를 송신할 수 있다. 샘플링 데몬(102)은, 모바일 디바이스(100)가 Wi-Fi에 연결되고, 외부 전력에 연결되는 경우 그리고 시스템이 열 이벤트를 경험하고 있지 않는 경우에 백그라운드 전송 데몬(1302)에 재시도 신호를 송신할 수 있다. 예를 들어, Wi-Fi에 연결되면, 데이터 사용량을 제어할 필요가 없을 수 있다. 유사하게, 외부 전력에 연결되면, 배터리 전력을 보존할 필요가 없을 수 있다. 따라서, 데이터 및 에너지 예산들은 승인 제어를 수행할 때 샘플링 데몬(102)에 의해 무시될 수 있다.

일부 구현들에서, 재시도 신호가 백그라운드 전송 데몬(1302)에 의해 수신되는 경우, 백그라운드 전송 데몬(1302)은 승인 요청을 샘플링 데몬(102)에 송신할 수 있다. 샘플링 데몬(102)이 승인 제어 요청에 응답하여 "좋음" 응답을 반환하는 경우, 백그라운드 전송 데몬(1302)은 애플리케이션(1304)에 대하여 백그라운드 다운로드 또는 업로드를 수행할 수 있다. 백그라운드 다운로드가 완료되면, 백그라운드 전송 데몬(1302)은 애플리케이션(1304)을 웨이크하거나 호출하고 다운로드된 데이터를 애플리케이션(1304)에 제공할 수 있다.

일부 구현들에서, 백그라운드 전송 데몬(1302)은 백그라운드 다운로드/업로드가 시작하고 종료할 때 샘플링 데몬(102)에 통지할 수 있어, 샘플링 데몬(102)은 모바일 디바이스(100) 상에서 수행되는 백그라운드 다운로드/업로드에 대해 예산들을 조정하고 통계치들을 유지할 수 있다. 예를 들어, 백그라운드 전송 데몬(1302)은 샘플링 데몬(102)에 "bac㎏roundTransfer" 속성 시작 또는 중지 이벤트를 송신할 수 있다. 일부 구현들에서, 백그라운드 전송 데몬(1302)은, 샘플링 데몬(102)이 모바일 디바이스(100) 상에서 수행되는 백그라운드 다운로드/업로드에 대해 예산들을 조정하고 통계치들을 유지할 수 있도록 셀룰러 데이터를 통해, Wi-Fi를 통해 그리고/또는 전체로서 전송되는 바이트들의 수(예를 들어, "system.networkBytes" 속성 이벤트)를 전송할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 백그라운드 전송 데몬(1302)에 타임아웃 값을 반환할 수 있다. 예를 들면, 타임아웃 값은 백그라운드 전송 데몬이 백그라운드 다운로드 또는 업로드를 수행해야 하는 일정 기간(예를 들어, 5분)을 나타낼 수 있다. 타임아웃 기간이 경과하는 경우, 백그라운드 전송 데몬(1302)은 백그라운드 다운로드 또는 업로드를 보류할 것이다.

일부 구현들에서, 타임아웃 값은 현재 시간에 대한 남은 에너지 예산들에 기초될 수 있다. 예를 들면, 샘플링 데몬(102)은 샘플링 데몬(102)에 의해 수집된 이벤트 이력 데이터에 기초하여 Wi-Fi를 통해 다운로드 또는 업로드를 수행하면서 얼마나 많은 에너지가 각 초 당 소비되는지를 결정할 수 있다. 샘플링 데몬(102)은 백그라운드 다운로드 또는 업로드를 수행하면서 에너지가 소비되는 레이트에 의해 남은 에너지 예산을 나눔으로써 타임아웃 기간을 결정할 수 있다(예를 들면, 에너지 예산/소비된 에너지/시간 = 타임아웃 기간).

일부 구현들에서, 백그라운드 다운로드 및/또는 업로드는 재개 가능하다. 예를 들면, 모바일 디바이스(100)가 WI-Fi 범위 밖으로 이동하면, 백그라운드 다운로드/업로드는 보류될 수 있다(예를 들어, 일시 중지). 모바일 디바이스(100)가 Wi-Fi 범위에 재진입하는 경우, 보류된 다운로드/업로드가 재개될 수 있다. 유사하게는, 백그라운드 다운로드/업로드가 에너지 예산 범위 밖에서 실행되면(예를 들어, 타임아웃 기간이 경과함), 백그라운드 다운로드/업로드가 보류될 수 있다. 추가 예산이 할당되는 경우(예를 들면, 다음 시간에서), 보류된 다운로드/업로드가 재개될 수 있다.

일부 구현들에서, 백그라운드 다운로드/업로드는 네트워크 연결의 품질에 기초하여 보류될 수 있다. 예를 들면, 모바일 디바이스(100)가 모바일 디바이스(100)와 서비싱 셀룰러 타워(servicing cellular tower) 사이에 양호한 셀룰러 데이터 연결, 및 셀룰러 타워와 모바일 디바이스(100)가 그로 또는 그로부터 데이터를 전송하는 서버 사이에 양호한 데이터 연결을 가질 수 있더라도, 모바일 디바이스(100)는 서버에 대해 양호한 연결을 갖지 않을 수 있다. 예를 들면, 모바일 디바이스(100)와 서버 사이의 전송 속도는 느릴 수 있거나 셀룰러 인터페이스의 처리율은 낮을 수 있다. 백그라운드 다운로드/업로드의 전송 속도가 임계 전송 속도 값 미만으로 떨어지고/지거나 백그라운드 다운로드/업로드의 처리율이 임계 처리율 값 미만으로 떨어지면, 백그라운드 다운로드/업로드(예를 들어, 데이터 전송)는 더 양호한 네트워크 연결이 이용 가능할 때까지 검출된 품질이 나쁜 네트워크 연결에 기초하여 보류되거나 일시 중지될 수 있다. 예를 들면, Wi-Fi 연결이 이용 가능하게 되면 보류된 백그라운드 다운로드/업로드는 Wi-Fi 연결을 통해 재개될 수 있다.

일부 구현들에서, 백그라운드 전송 데몬(1302)은 한 번에 수행될 수 있는 백그라운드 다운로드 및/또는 업로드의 수에 대한 제한으로 구성될 수 있다. 예를 들면, 백그라운드 전송 데몬(1302)은 동시에 발생하는 백그라운드 다운로드 및/또는 업로드의 수를 3개로 제한할 수 있다.

예시적인 백그라운드 다운로드/업로드 프로세스

도 14는 백그라운드 다운로드 및 업로드를 수행하기 위한 예시적인 프로세스(1400)의 흐름도이다. 예를 들면, 백그라운드 다운로드 및/또는 업로드는 백그라운드 전송 데몬(1302)에 의해 모바일 디바이스(100) 상의 애플리케이션들 대신에 수행될 수 있다.

단계(1402)에서, 백그라운드 전송 요청이 수신될 수 있다. 예를 들면, 백그라운드 전송 데몬(1302)은 모바일 디바이스(100) 상에서 실행되는 애플리케이션으로부터 백그라운드 다운로드/업로드 요청을 수신할 수 있다. 애플리케이션이 요청을 하면, 애플리케이션은 예를 들면 종료되거나 보류될 수 있다. 요청은 애플리케이션을 식별하고 데이터에 대한 소스 및/또는 목적지 위치들을 식별할 수 있다. 예를 들면, 데이터를 다운로드하는 경우, 소스 위치는 서버에 대한 네트워크 어드레스일 수 있고 목적지 위치는 모바일 디바이스(100)의 파일 시스템 내의 디렉토리일 수 있다. 데이터를 업로드하는 경우, 소스 위치는 파일 시스템 위치일 수 있고 목적지는 네트워크 위치일 수 있다.

단계(1404)에서, 모바일 디바이스(100)는 예산들 및 디바이스 상태들이 데이터 전송을 허용하지 않음을 결정할 수 있다. 예를 들어, 백그라운드 전송 데몬(1302)은 백그라운드 전송 데몬(1302), 백그라운드 전송이 수행되고 있는 애플리케이션, 및/또는 전송될 데이터의 양을 식별하는 승인 제어 요청을 샘플링 데몬(102)에 함으로써, 요청된 백그라운드 전송을 수행하는 것이 좋은지 여부를 샘플링 데몬(102)에 질의할 수 있다. 샘플링 데몬(102)은 에너지 및 데이터 예산들이 고갈되는지 여부 및 모바일 디바이스(100)가 열 이벤트 중에 있는지 여부를 결정할 수 있다. 예산들이 고갈되면 또는 모바일 디바이스(100)가 열 이벤트 중에 있으면, 샘플링 데몬(102)은 백그라운드 데이터 전송을 수행해서는 안된다는 것을 나타내는 메시지를 백그라운드 전송 데몬(1302)에 송신할 수 있다(예를 들어, 승인 제어가 "아니오"를 반환함).

단계(1406)에서, 모바일 디바이스(100)는 백그라운드 전송 요청을 저장할 수 있다. 예를 들어, 백그라운드 전송 데몬(1302)은 샘플링 데몬(102)이 승인 제어 요청에 응답하여 "아니오" 값을 반환할 때 전송 요청 저장소에 전송 요청을 저장할 수 있다.

단계(1408)에서 모바일 디바이스(100)는 백그라운드 전송을 재시도해도 좋음을 결정할 수 있다. 예를 들면, 샘플링 데몬(102)은 데이터 및 에너지 예산들이 보충되었음을 그리고 모바일 디바이스(100)가 열 이벤트 중에 있지 않음을 결정할 수 있다. 샘플링 데몬(102)은 재시도 메시지를 백그라운드 전송 데몬(1302)에 송신할 수 있다. 이어서, 백그라운드 전송 데몬(1302)은 저장된 전송 요청들 각각에 대해 다른 승인 제어 요청을 함으로써 전송 요청 저장소에 저장된 요청된 전송들을 수행하려고 시도할 수 있다.

단계(1410)에서, 모바일 디바이스(100)는 모바일 디바이스(100)의 예산들 및 상태들이 백그라운드 데이터 전송을 허용함을 결정할 수 있다. 예를 들면, 백그라운드 전송 데몬(1302)은 요청된 백그라운드 전송을 수행해도 좋은지 여부를 샘플링 데몬(102)에 질의할 수 있다. 샘플링 데몬(102)은 에너지 및 데이터 예산들이 고갈되고, 모바일 디바이스(100)가 열 이벤트 중에 있지 않음을 결정하기 위해 승인 제어를 수행할 수 있다. 예산들이 고갈되지 않으면 그리고 모바일 디바이스(100)가 열 이벤트 중에 있지 않으면, 샘플링 데몬(102)은 백그라운드 데이터 전송을 수행해도 좋음을 나타내는 메시지를 백그라운드 전송 데몬(1302)에 송신할 수 있다.

단계(1412)에서, 모바일 디바이스(100)는 백그라운드 전송을 수행할 수 있다. 예를 들면, 백그라운드 전송 데몬(1302)은 요청 애플리케이션에 대해 요청된 백그라운드 다운로드 또는 백그라운드 업로드를 수행할 수 있다. 백그라운드 전송 데몬(1302)은 (예를 들어, "backgroundTransfer" 속성 시작 및 중지 이벤트들을 사용하여) 백그라운드 전송이 시작되고 종료될 때 샘플링 데몬(102)에 통지할 수 있다. 백그라운드 전송 데몬(1302)은 (예를 들어, "networkBytes" 속성 이벤트를 사용하여) 백그라운드 다운로드 또는 업로드 동안 전송되는 바이트들의 수를 샘플링 데몬에 알리는 메시지를 송신할 수 있다. 백그라운드 전송이 완료되면, 백그라운드 전송 데몬(1302)은 백그라운드 전송 요청을 한 애플리케이션을 호출(예를 들어, 개시 또는 웨이크)하고 완료 상태 정보(예를 들어, 성공, 오류, 다운로드된 데이터 등)를 요청 애플리케이션에 송신할 수 있다.

백그라운드 업데이트를 인에이블/디스에이블

도 15는 모바일 디바이스 상에서 애플리케이션들에 대한 백그라운드 업데이트들을 인에이블 및/또는 디스에이블하기 위한 예시적인 그래픽 사용자 인터페이스(GUI)(1500)를 예시한다. 예를 들면, GUI(1500)는 모바일 디바이스(100) 상의 애플리케이션에 대한 백그라운드 업데이트 설정을 조정하기 위하여 사용자 입력을 수신하기 위한 모바일 디바이스(100)의 디스플레이 상에 보여지는 인터페이스일 수 있다.

일부 구현들에서, GUI(1500)로의 사용자 입력은 전술한 바와 같이, 사용자 호출 예측에 기초하여 애플리케이션들에 대해 수행되는 것으로부터 백그라운드 업데이트들을 인에이블 또는 디스에이블할 수 있다. 예를 들면, 샘플링 프로세스(102) 및/또는 애플리케이션 관리자(106)는 백그라운드 업데이트들이 애플리케이션에 대해 인에이블되거나 디스에이블되는지 여부를 결정하고, 애플리케이션이 애플리케이션 관리자(106)에 의해 개시되는 것을 방지하거나 애플리케이션이 샘플링 데몬(102)에 의해 생성된 애플리케이션 호출 예측 내에 포함되는 것을 방지할 수 있다. 예를 들면, 백그라운드 업데이트들이 애플리케이션에 대해 디스에이블되면, 샘플링 데몬(102)은 사용자 호출된 애플리케이션 예측이 애플리케이션 관리자(106)에 의해 요청된 애플리케이션을 포함하지 않을 것이다. 따라서, 애플리케이션 관리자(106)는 백그라운드 업데이트들이 디스에이블될 때 애플리케이션을 개시하지 않을 것이다. 반대로, 백그라운드 업데이트들이 애플리케이션에 대해 인에이블되면, 애플리케이션은 전술한 바와 같이 사용자 호출 확률들에 기초하여 샘플링 데몬(102)에 의해 생성된 애플리케이션 호출 예측에 포함될 수 있다.

일부 구현들에서, GUI(1500)로의 사용자 입력은 전술한 바와 같이 푸시 통지가 수신될 때 애플리케이션에 대해 수행되는 것으로부터 백그라운드 업데이트들을 인에이블 또는 디스에이블할 수 있다. 예를 들면, 샘플링 데몬(102), 애플리케이션 관리자(106) 및/또는 푸시 서비스 데몬(904)은, 백그라운드 업데이트들이 애플리케이션에 대해 인에이블되거나 디스에이블되는지 여부를 결정하고, 푸시 통지를 수신하는 것에 응답하여 애플리케이션 관리자(106)에 의해 애플리케이션이 개시되는 것을 방지할 수 있다. 예를 들면, 백그라운드 업데이트들이 애플리케이션에 대해 디스에이블되고 푸시 통지가 애플리케이션에 대해 수신되면, 애플리케이션 관리자(106)는 푸시 통지에 응답하여 업데이트들을 다운로드하기 위해 애플리케이션을 개시하지 않을 것이다.

일부 구현들에서, GUI(1500)는 백그라운드 업데이트들을 수행하도록 구성된 애플리케이션들(1502 내지 1514)을 표시할 수 있다. 예를 들면, 애플리케이션들(1502 내지 1514)은 애플리케이션 관리자(106)에 의해 개시될 때 모바일 디바이스(100) 상에서 백그라운드 프로세스들로서 실행되도록 구성되고 프로그래밍될 수 있다. 백그라운드 프로세스로서 실행되는 경우, 애플리케이션들(1502 내지 1514)은 다양한 네트워크 리소스들과 통신하여 현재 또는 업데이트된 콘텐츠를 다운로드할 수 있다. 이어서, 애플리케이션들(1502 내지 1514)은 모바일 디바이스(100)의 사용자에 의해 호출될 때 업데이트된 콘텐츠를 보여주기 위하여 그것들 각자의 사용자 인터페이스들을 업데이트할 수 있다. 일부 구현들에서, 백그라운드 업데이트들을 수행하도록 구성되지 않거나 프로그래밍되지 않은 애플리케이션들은 GUI(1500) 상에 표시되지 않을 것이다.

일부 구현들에서, 사용자는 GUI(1500)에 입력을 제공하여 애플리케이션에 대한 백그라운드 업데이트들을 인에이블 및/또는 디스에이블할 수 있다. 예를 들면, 사용자는 토글(1516)에 관하여 모바일 디바이스(102)에 입력(예를 들어, 터치 입력)을 제공하여 애플리케이션(1502)에 대한 백그라운드 업데이트들을 켜거나 끌 수 있다. 사용자는 토글(1518)에 관하여 모바일 디바이스(102)에 입력(예를 들어, 터치 입력)을 제공하여 애플리케이션(1508)에 대한 백그라운드 업데이트들을 켜거나 끌 수 있다.

일부 구현들에서, 추가 옵션들이 GUI(1500)를 통해 백그라운드 업데이트 애플리케이션에 대해 특정될 수 있다. 예를 들면, 사용자는 애플리케이션(1514)과 연관된 그래픽 객체(1510)를 선택하여, 추가 백그라운드 업데이트 옵션들을 특정하기 위한 그래픽 사용자 인터페이스(도시되지 않음)를 호출할 수 있다. 백그라운드 업데이트 옵션들은 예를 들면, 애플리케이션(1514)에 대한 백그라운드 업데이트들을 켜고/거나 끄기 위한 시작 시간 및 종료 시간을 포함할 수 있다.

피어 디바이스들 사이의 데이터 공유

도 16은 피어 디바이스들 사이에서 데이터를 공유하기 위한 예시적인 시스템을 예시한다. 일부 구현들에서, 모바일 디바이스(100)는 모바일 디바이스(1600)와 이벤트 데이터, 시스템 데이터 및/또는 이벤트 예측들을 공유할 수 있다. 예를 들어, 모바일 디바이스(100) 및 모바일 디바이스(1600)는 동일한 사용자에 의해 소유된 디바이스들일 수 있다. 따라서, 모바일 디바이스(100)와 모바일 디바이스(1600) 사이에서 각 디바이스에 대한 사용자의 활동들에 관한 정보를 공유하는 것이 유익할 수 있다.

일부 구현들에서, 모바일 디바이스(1600)는 전술한 모바일 디바이스(100)와 유사하게 구성될 수 있다. 예를 들어, 모바일 디바이스(1600)는 상기 단락들에 기술된 기능들(예를 들어, 속성, 속성 이벤트, 예측, 승인 제어 등)을 제공하는 샘플링 데몬(1602)으로 구성될 수 있다.

일부 구현들에서, 모바일 디바이스(100) 및 모바일 디바이스(1600)는 각각 아이덴티티 서비스 데몬(1620) 및 아이덴티티 서비스 데몬(1610)으로 구성될 수 있다. 예를 들어, 아이덴티티 서비스 데몬(1620, 1610)은 모바일 디바이스(100)와 모바일 디바이스(1600) 사이에서 정보를 통신하도록 구성될 수 있다. 아이덴티티 서비스 데몬은 다양한 피어-투-피어 및 네트워크 연결들을 통해 동일한 사용자에 의해 소유된 디바이스들 사이에서 데이터를 공유하는 데 사용될 수 있다. 예를 들어, 아이덴티티 서비스 데몬(1620) 및 아이덴티티 서비스 데몬(1610)은 블루투스, 저전력 블루투스, Wi-Fi, LAN, WAN 및/또는 인터넷 연결들을 통해 정보를 교환할 수 있다.

일부 구현들에서, 샘플링 데몬(1602)(및 샘플링 데몬(102))은 이벤트 예측들 및 시스템 상태 정보를 동일한 사용자에 의해 소유된 다른 디바이스들 상에서 실행되는 다른 샘플링 데몬과 공유하도록 구성될 수 있다. 예를 들어, 모바일 디바이스(100) 및 모바일 디바이스(1600)가 동일한 사용자에 의해 소유되면, 샘플링 데몬(102) 및 샘플링 데몬(1602)은 이벤트 예측 정보 및/또는 시스템 상태 정보(예를 들어, 배터리 상태)를 교환할 수 있다. 예를 들어, 샘플링 데몬(1602)은 아이덴티티 서비스 데몬(1610)을 사용하여 이벤트 예측 정보 및/또는 시스템 상태 정보를 송신할 수 있다. 아이덴티티 서비스 데몬(1610)은 아이덴티티 서비스 데몬(1620)에 대한 연결을 구축하고 아이덴티티 서비스 데몬(1620)을 통해 샘플링 데몬(102)에 이벤트 예측 정보 및/또는 모바일 디바이스(1600) 시스템 상태 정보를 전달할 수 있다.

일부 구현들에서, 애플리케이션(1608)(예를 들어, 샘플링 데몬(1602)의 클라이언트)은, 샘플링 데몬(1602)이 특정된 속성 또는 속성 값에 대한 이벤트 예측들을 샘플링 데몬(102)에 송신할 것을 요청할 수 있다. 예를 들어, 애플리케이션(1608)은 모바일 디바이스(100)의 애플리케이션(108)과 동기화되는 애플리케이션일 수 있다. 예를 들어, 애플리케이션들(108, 1608)은 모바일 디바이스(100)와 모바일 디바이스(1600) 사이의 데이터(예를 들어, 미디어 파일, 메시지, 상태 정보 등)를 동기화하도록 구성된 미디어 애플리케이션들(예를 들어, 음악 라이브러리, 비디오 라이브러리, 이메일 애플리케이션, 메시징 애플리케이션 등)일 수 있다.

일부 구현들에서, 피어 디바이스(예를 들어, 모바일 디바이스(100))로 하여금 디바이스들 사이의 데이터를 언제 동기화할지를 결정하도록 하기 위해, 애플리케이션(1608)은, 샘플링 데몬(1602)이 모바일 디바이스(1600)에 의해 생성된 속성 이벤트 데이터에 기초하여 "bundleId" 속성 또는 특정 "bundleId" 속성 값(예를 들어, 애플리케이션(1608)에 대한 애플리케이션 식별자)에 대한 시간 및/또는 피어 예측들을 생성하고 예측들을 샘플링 데몬(102)에 전송할 것을 요청할 수 있다. 예를 들어, 피어 디바이스는 동일한 사용자에 의해 소유된 원격 디바이스(예를 들어, 현재 로컬 디바이스가 아님)일 수 있다. 모바일 디바이스(100)는 예를 들어, 모바일 디바이스(1600)의 피어 디바이스일 수 있다.

일부 구현들에서, 요청 클라이언트(예를 들어, 애플리케이션(1608))는 전달을 위한 스케줄 및 예측된 데이터의 지속기간을 특정할 수 있다. 예를 들어, 애플리케이션(1608)은 "bundleId" 속성 값 "mailapp"에 대한 피어 및/또는 시간 예측을 요청할 수 있다. 애플리케이션(1608)은, 예측이 매주 생성되고 교환될 것을, 그리고 각각의 예측이 예를 들어, 일주일의 기간 또는 지속기간을 커버할 것을 요청할 수 있다.

일부 구현들에서, 피어 디바이스들 사이의 데이터 교환들은 정적으로 스케줄링될 수 있다. 샘플링 데몬(1602)은 모바일 디바이스(100)가 엄격한 스케줄(예를 들어, 24시간마다의 애플리케이션 예측들 및 배터리 통계치들) 하에서 모바일 디바이스(1600)의 원격 상태의 일관된 뷰를 갖도록 하는 데 필요한 속성 데이터를 송신할 수 있다. 일부 구현들에서, 클라이언트는 피어 디바이스로부터의 요구에 따라 속성 예측들 또는 통계치들을 요청할 수 있다. 이러한 교환들은 비반복적이다. 요청 클라이언트는 요청된 데이터가 수신될 때 통지받을 수 있다.

일부 구현들에서, 샘플링 데몬(1602)은 모바일 디바이스(1600)에 대한 시스템 상태 데이터를 샘플링 데몬(102)에 전송할 수 있다. 예를 들면, 샘플링 데몬(1602)은 배터리 충전 레벨 이벤트(예를 들어, "batteryLevel" 속성 이벤트), 배터리 충전 이벤트(예를 들어, "cableplugin" 이벤트), 에너지 사용 이벤트(예를 들어, "energy" 속성 이벤트) 및/또는 배터리 사용 및 충전 통계치를 생성하고 배터리-관련 이벤트 데이터를 샘플링 데몬(102)에 전송하는 데 사용될 수 있는 다른 이벤트들을 수신할 수 있다. 예를 들어, 배터리 상태 정보가 24시간마다 교환될 수 있다. 배터리 상태 정보는 기회주의적으로 교환될 수 있다. 예를 들면, 통신 채널(예를 들어, 피어-투-피어, 네트워크 등)이 모바일 디바이스(100)와 모바일 디바이스(1600)로 구축되면, 모바일 디바이스들은 기회주의적으로 이미 개방된 통신 채널을 사용하여 배터리 상태 또는 다른 시스템 상태 정보(예를 들어, 현재 포그라운드 애플리케이션의 식별)를 교환할 수 있다.

다른 예로서, 샘플링 데몬(1602)은 열 레벨 이벤트(예를 들어, "thermalLevel" 속성 이벤트), 네트워크 이벤트(예를 들어, "networkQuality" 속성 이벤트, "networkBytes" 속성 이벤트)를 수신하고 열 및/또는 네트워크 이벤트를 샘플링 데몬(102)에 전송할 수 있다. 샘플링 데몬(1602)은 어떤 애플리케이션(예를 들어, 애플리케이션 식별자)이 현재 모바일 디바이스(1600)의 포그라운드에 있는지를 나타내는 애플리케이션 관리자(106)로부터의 이벤트(예를 들어, "system.foregroundApp" 속성 이벤트)를 수신하고 포그라운드 애플리케이션 정보를 샘플링 데몬(102)에 전송할 수 있다. 일부 구현들에서, 열 이벤트 및 포그라운드 애플리케이션 변경 정보는 이벤트가 발생하자마자(예를 들어, 피어 디바이스들 사이에 연결이 구축되자마자) 피어 디바이스들과 교환될 수 있다. 일부 구현들에서, 네트워크 상태 정보는 주기적으로(예를 들어, 1일 1회, 1일 2회, 매시간 등) 교환될 수 있다.

샘플링 데몬(1602)으로부터의 예측 및/또는 시스템 이벤트 데이터의 수신시, 샘플링 데몬(102)은 예측 및/또는 이벤트 데이터를 피어 데이터 저장소(1622)에 저장할 수 있다. 유사하게, 샘플링 데몬(1602)이 샘플링 데몬(102)으로부터 수신하는 임의의 예측 및/또는 이벤트 데이터는 피어 데이터 저장소(1612)에 저장될 수 있다. 일부 구현들에서, 다른 디바이스로부터 수신된 예측 및/또는 이벤트 데이터는 디바이스 디바이스 설명과 연관될 수 있다. 예를 들어, 디바이스 설명은 디바이스 이름, 디바이스 식별자 및 디바이스의 모델을 식별하는 모델 식별자를 포함할 수 있다. 디바이스 설명은 피어 데이터 저장소(1622)에서 디바이스에 대한 예측 데이터 및/또는 이벤트 데이터를 검색하는 데 사용될 수 있다. 모바일 디바이스(100) 및 모바일 디바이스(1600)가 예측 및/또는 이벤트 데이터를 교환했으면, 모바일 디바이스들은 교환된 정보를 사용하여, 아래의 원격 승인 제어 메커니즘을 사용하여 서로 언제 통신할지를 결정할 수 있다. 정보가 필요할 때 그리고 디바이스들의 배터리 상태가 정보를 공유하는 것을 지원할 수 있을 때에만 디바이스들이 정보를 공유할 수 있게 함으로써, 통신의 전력 관리가 향상될 수 있다.

원격 승인 제어

일부 구현들에서, 모바일 디바이스(100)(또는 모바일 디바이스(1600))는 다른 디바이스로부터 수신된 데이터에 기초하여 승인 제어를 수행할 수 있다. 예를 들면, 샘플링 데몬(102)은 샘플링 데몬(1602)으로부터 수신되고 피어 데이터 저장소(1622)에 저장된 예측 및 시스템 이벤트 데이터에 기초하여 승인 제어를 수행할 수 있다. 예를 들어, 애플리케이션(1608)과 데이터를 동기화하기 위해, 애플리케이션(108)은 동기화 메시지를 아이덴티티 서비스 데몬(1620)에 송신할 수 있다. 예를 들어, 동기화 메시지는 모바일 디바이스(100)에 대한 식별자, 모바일 디바이스(1600)에 대한 식별자, 우선순위 식별자(예를 들어, 하이, 로우), 및 메시지 페이로드(예를 들어, 동기화될 데이터)를 포함할 수 있다.

낮은 우선순위 메시지

일부 구현들에서, 낮은 우선순위 메시지는 승인 제어를 거친 후에 전송될 수 있다. 예를 들어, 낮은 우선순위 메시지는 임의 처리(discretionary processing)(예를 들어, 백그라운드 애플리케이션, 시스템 유틸리티, 예상 활동, 사용자가 시작하지 않은 활동)와 연관된 메시지일 수 있다. 예를 들어, 아이덴티티 서비스 데몬(1620)은 애플리케이션(1608)에 대한 번들 식별자인 "bundleId" 속성 값(예를 들어, "bundleId" = "1608")에 대한 승인 제어 요청을 샘플링 데몬(102)에 송신할 수 있다. "bundleId" 속성 이름 및 값(예를 들어, "1608")에 추가하여, 아이덴티티 서비스 데몬(1620)은 애플리케이션(108)이 다른 디바이스와의 통신에 대한 승인 제어를 요청하고 있음을 나타내기 위해 승인 제어 요청 내에 디바이스 이름(예를 들어, "device1600")을 제공할 수 있다.

일부 구현들에서, 승인 제어 요청을 수신하는 것에 응답하여, 샘플링 데몬(102)은 로컬 승인 제어 및 원격 승인 제어를 수행할 수 있다. 예를 들면, 샘플링 데몬(102)은 모바일 디바이스(100)가 특정된 속성 값(예를 들어, "bundleId" = "1608")과 연관된 이벤트가 발생하는 것을 허용하는 상태에 있는지를 결정하기 위해, 전술한 바와 같이, 로컬 승인 제어를 수행할 수 있다. 샘플링 데몬(102)은 예를 들어, 로컬 에너지, 데이터 및 속성 예산들을 체크할 수 있고, 모바일 디바이스(100)가 특정된 속성 값(예를 들어, "bundleId" = "1608")과 연관된 이벤트를 허용하는 상태에 있는지 여부를 결정하기 위해 투표자 피드백을 요구할 수 있다.

로컬 승인 제어를 수행하는 것에 추가하여, 샘플링 데몬(102)은 모바일 디바이스(1600)로부터 수신되고 피어 데이터 저장소(1622)에 저장된 "bundleId" 속성 예측, 이벤트 데이터 및 시스템 데이터에 기초하여 원격 승인 제어를 수행할 수 있다. 예를 들어, 샘플링 데몬(102)은 피어 데이터 저장소(1622)에서 모바일 디바이스(1600)와 연관된 데이터의 위치를 찾기 위해 디바이스 식별자(예를 들어, "device1600", 디바이스 이름, 고유 식별자, UUID 등)를 사용할 수 있다. 샘플링 데몬(102)은 샘플링 데몬(1602)으로부터 수신된 속성(예를 들어, "bundleId") 예측 데이터를 분석하여 애플리케이션(1608)이 현재 15분 타임슬롯에서 모바일 디바이스(1600) 상에서 사용자에 의해 호출될 가능성이 있는지를 결정할 수 있다. 애플리케이션(1608)이 현재 15분 타임슬롯에서 사용자에 의해 호출될 가능성이 없다면, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 "아니오" 값을 반환할 수 있다. 예를 들어, 애플리케이션(1608)이 모바일 디바이스(1600) 상에서 사용될 가능성이 있을 때에만 애플리케이션(108)이 애플리케이션(1608)과 동기화하도록 허용함으로써, 샘플링 데몬(102)은 사용자가 모바일 디바이스(1600) 상에서 애플리케이션(1608)을 사용할 가능성이 있을 때와 같은 시간까지 동기화 프로세스를 지연시키고 시스템 리소스들(예를 들어, 배터리, CPU 사이클, 네트워크 데이터)을 보존할 수 있다.

일부 구현에서, 애플리케이션(1608)이 현재 15분 타임슬롯에서 모바일 디바이스(1600)의 사용자에 의해 호출될 가능성이 있다면, 샘플링 데몬(102)은 모바일 디바이스(1600)와 연관되고 피어 데이터 저장소(1622)에 저장된 시스템 데이터를 체크할 수 있다. 예를 들어, 샘플링 데몬(102)은 모바일 디바이스(1600)가 애플리케이션(108)과 애플리케이션(1608) 사이의 동기화를 수행하기에 충분한 배터리 충전이 남아있는지를 결정하기 위해 모바일 디바이스(1600)와 연관된 시스템 데이터를 체크할 수 있다. 예를 들어, 샘플링 데몬(102)은 현재 애플리케이션(108)과 애플리케이션(1608) 사이의 동기화를 완료하기에 충분한 배터리 충전이 있는지를 체크할 수 있다. 샘플링 데몬(102)은 동기화를 수행하기에 충분한 배터리 충전이 있는지 여부를 체크하고, 다음 예측된 배터리 재충전(예를 들어, "cablePlugin" 속성 이벤트)까지 동작을 계속할 수 있다. 예를 들어, 샘플링 데몬(102)은 다음 "cablePlugin" 속성 이벤트가 언제 발생할 가능성이 있는지를 식별하는 "cablePlugin" 속성에 대한 시간 예측을 생성할 수 있다. 샘플링 데몬(102)은 다음 "cablePlugin" 이벤트까지 에너지 사용을 예측하기 위해 에너지 사용 통계치(이벤트들)를 분석하고, 애플리케이션(108)과 애플리케이션(1608) 사이의 동기화 전송을 서비스하기에 충분한 잔여 에너지가 있는지를 결정할 수 있다. 샘플링 데몬(102)이 모바일 디바이스(1600)가 동기화를 서비스하기에 충분한 에너지(예를 들어, 배터리 충전)를 갖지 않음을 결정하면, 샘플링 데몬(102)은 원격 승인 제어 요청에 응답하여 "아니오" 값을 반환할 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 모바일 디바이스(1600)가 정상 열 상태(예를 들어, 너무 뜨겁지는 않음)에 있는지를 결정하기 위해 모바일 디바이스(1600)와 연관된 시스템 데이터를 체크할 수 있고 동기화 요청을 처리할 수 있다. 예를 들어, 모바일 디바이스(1600)로부터 수신된 "thermalLevel" 속성 이벤트 데이터가 모바일 디바이스(1600)가 임계값보다 높은 온도에서 현재 동작하고 있음을 나타내는 경우, 샘플링 데몬(102)은 원격 승인 제어 요청에 응답하여 "아니오" 값을 반환함으로써 동기화 통신을 방지할 수 있다.

일부 구현들에서, 예측된 데이터가 사용자가 모바일 디바이스(1600) 상의 애플리케이션(1608)을 호출할 가능성이 있음을 나타내고, 에너지, 열 및 다른 시스템 상태 정보가 모바일 디바이스(1600)가 모바일 디바이스(100)로부터의 통신을 처리하는 상태에 있음을 나타내는 경우, 샘플링 데몬(102)은 승인 제어 요청에 응답하여 아이덴티티 서비스 데몬(1620)에 "예" 값을 반환할 수 있다. 승인 제어 요청에 응답하여 "예" 값을 수신하는 것에 응답하여, 아이덴티티 서비스 데몬(1620)은 애플리케이션(108)에 대한 동기화 메시지를 모바일 디바이스(1600) 상의 아이덴티티 서비스 데몬(1610)에 전송할 수 있다. 이어서 애플리케이션(108) 및 애플리케이션(1608)은 아이덴티티 서비스 데몬(1620) 및 아이덴티티 서비스 데몬(1610)을 통해 메시지들을 교환함으로써 데이터를 동기화할 수 있다.

일부 구현에서, 높은 우선순위 메시지는 원격 승인 제어를 거친 후에 전송될 수 있다. 예를 들어, 높은 우선순위 메시지는 포그라운드 애플리케이션과 연관된 메시지 또는 사용자가 입력을 제공하는 것에 응답하여 생성된 메시지와 같은, 사용자 시작된 태스크와 연관된 메시지일 수 있다. 일부 구현들에서, 높은 우선순위의 메시지에 대한 승인 제어는 낮은 우선순위 메시지와 유사하게 처리될 수 있다. 그러나, 높은 우선순위 메시지에 대한 원격 승인 제어를 수행할 때, 높은 우선순위 메시지는, 높은 우선순위 메시지가 일반적으로 소정의 임의 백그라운드 태스크에 의해 개시되는 대신에 소정의 사용자 행위에 의해 트리거되기 때문에, 속성 예측 데이터(예를 들어, "bundleId" 예측 데이터)를 고려하지 않고 인정될(허용될) 수 있다.

일부 구현들에서, 높은 우선순위 메시지들에 대한 승인 제어를 수행할 때, 원격 디바이스(예를 들어, 모바일 디바이스(1600))의 배터리 상태는 원격 디바이스(예를 들어, 피어 디바이스)가 높은 우선순위 메시지를 처리하기에 이용 가능한 충분한 배터리 충전을 갖는다는 것을 확인하기 위해 체크될 수 있다. 원격 디바이스 상에 이용 가능한 충분한 배터리 충전이 있다면, 높은 우선순위 메시지는 원격 승인 제어에 의해 승인될 것이다. 예를 들어, 샘플링 데몬(102)은 높은 우선순위 메시지를 처리하기에 충분한 배터리 충전이 남아있을 때 원격 승인 제어 요청에 응답하여 아이덴티티 서비스 데몬(1620)에 "예" 값을 전송할 수 있다. 원격 디바이스 상에 이용 가능한 충분한 배터리 충전이 있지 않다면, 높은 우선순위 메시지는 원격 승인 제어에 의해 거절될 것이다. 예를 들어, 샘플링 데몬(102)은 높은 우선순위 메시지를 처리하기에 충분한 배터리 충전이 남아있을 때 원격 승인 제어 요청에 응답하여 아이덴티티 서비스 데몬(1620)에 "아니오" 값을 전송할 수 있다. 따라서, 아이덴티티 서비스 데몬(1620)은 피어 디바이스가 해당 메시지를 처리하기에 충분한 배터리 충전을 가질 때 피어 디바이스(예를 들어, 모바일 디바이스(1600))와의 통신을 개시할 것이다.

일부 구현들에서, 샘플링 데몬(102)이 높은 우선순위 메시지를 통지받는 경우, 샘플링 데몬(102)은 현재 배터리 상태 정보(예를 들어, 현재 충전 레벨)를 아이덴티티 서비스 데몬(1620)에 송신할 수 있다. 이어서 아이덴티티 서비스 데몬(1620)은 배터리 상태 정보를 높은 우선순위 메시지에 추가할 수 있다. 따라서, 시스템 상태 정보는 모바일 디바이스(100)와 모바일 디바이스(1600) 사이에서 전송되는 다른 메시지들에 배터리 상태 정보(또는 다른 정보, 예를 들어, 열 레벨, 포그라운드 애플리케이션 등)를 피기백(piggy back)시킴으로써 디바이스들 사이에 효율적으로 공유될 수 있다.

일부 구현들에서, 샘플링 데몬(102)은 재시도 메시지를 아이덴티티 서비스 데몬(1620)에 송신할 수 있다. 예를 들어, 모바일 디바이스(100) 또는 모바일 디바이스(1600) 상의 상태들이 변화할 때(예를 들어, 배터리 상태가 향상될 때), 샘플링 데몬(102)은 아이덴티티 서비스 데몬(1620)에 재시도 메시지를 송신할 수 있다. 일부 구현들에서, 원격 초점(focal) 애플리케이션이 변화할 때 재시도 메시지가 생성될 수 있다. 예를 들어, 원격 피어 디바이스 상의 사용자가 "mailapp" 애플리케이션을 사용하고 있는 경우, "mailapp" 애플리케이션은 초점 애플리케이션이 된다. 사용자가 "webbrowser" 애플리케이션을 사용하기 시작하면, 초점 애플리케이션은 "webbrowser" 애플리케이션으로 변화한다. 초점 애플리케이션의 변화는 피어 데이터가 모바일 디바이스(100)와 모바일 디바이스(1600) 사이에서 교환될 때 샘플링 데몬(1602)에 이벤트로서 보고되고 샘플링 데몬(102)에 전송될 수 있다. 피어 디바이스(1602)에서 초점 애플리케이션의 변화를 나타내는 이벤트 정보를 수신하면, 샘플링 데몬(102)은 재시도 메시지를 아이덴티티 서비스 데몬(1620)에 송신할 수 있다. 이어서, 아이덴티티 서비스 데몬(1620)은 샘플링 데몬(102)에 의해 거절된 각 메시지에 대한 승인 제어를 재시도할 수 있다. 예를 들어, 아이덴티티 서비스 데몬(1620)은 샘플링 데몬(102)으로부터 재시도 메시지가 수신될 때 거절된 메시지들(예를 들어, 전송 태스크들)을 저장할 수 있고 거절된 메시지들을 승인 제어를 통해 송신할 수 있다. 일부 구현들에서, 거절된 메시지들은 일정 기간이 경과한 후에 전송될 수 있다. 예를 들어, 승인 제어를 통과하지 못한 메시지는 구성가능한 시간 기간이 경과한 후에 피어 디바이스에 송신될 수 있다.

일부 구현들에서, 아이덴티티 서비스 데몬(1620)은 샘플링 데몬(102)이 모바일 디바이스(100) 또는 모바일 디바이스(1600) 상의 상태들이 변화했음을 나타낼 때 데이터 스트림 전송을 인터럽트할 수 있다. 예를 들어, 샘플링 데몬(102)이 모바일 디바이스(100) 또는 모바일 디바이스(1600) 상의 배터리 상태가 변화되어 모바일 디바이스들 중 하나가 배터리 전력이 떨어졌을 수 있다고 결정하면, 샘플링 데몬(102)은 아이덴티티 서비스 데몬(1620)에게 전송을 중지하고 데이터 스트림과 연관된 속성 이벤트에 대한 승인 제어를 재시도하라고 명할 수 있다.

피어 디바이스들 사이에서 데이터를 공유하기 위한 프로세스

도 17은 피어 디바이스들 사이에서 데이터를 공유하기 위한 예시적인 프로세스(1700)를 예시한다. 프로세스(1700)에 대한 추가 상세 사항들은 도 16을 참조하여 위에서 발견될 수 있다. 단계(1702)에서, 모바일 디바이스는 피어 디바이스로부터 이벤트 데이터를 수신할 수 있다. 예를 들어, 이벤트 데이터는 "digests"(예를 들어, 예측, 통계치 등) 또는 원시(예를 들어, 미처리된) 이벤트 데이터로서 공유될 수 있다. 예를 들어, 제2 디바이스(예를 들어, 모바일 디바이스(1600))는 제2 디바이스 및 모바일 디바이스(100)가 동일한 사용자에 의해 소유될 때 그 모바일 디바이스의 피어 디바이스이다. 모바일 디바이스(100)는 모바일 디바이스(1600)의 시스템 상태(예를 들어, 배터리 상태, 네트워크 상태, 포그라운드 애플리케이션 식별자 등)와 관련된 이벤트 데이터를 수신할 수 있다. 모바일 디바이스는 모바일 디바이스(1600) 상에서 발생한 이벤트들에 기초하여 모바일 디바이스(1600)로부터 속성 이벤트 예측, 통계치 또는 원시 이벤트 데이터를 수신할 수 있다. 예를 들어, 피어 디바이스(1600) 상의 애플리케이션(1608)은 피어 디바이스(1600) 상의 샘플링 데몬(1602)에게 특정 속성 또는 속성 값에 대한 예측을 생성하여 모바일 디바이스(100)로 송신하도록 지시할 수 있다.

단계(1704)에서, 모바일 디바이스(100) 상의 아이덴티티 서비스 데몬(1620)은 피어 디바이스(1600)에 전송할 메시지를 수신할 수 있다. 예를 들어, 모바일 디바이스 상에서 실행되는 애플리케이션(108)은 피어 디바이스(1600) 상의 대응하는 애플리케이션(1608)과 데이터를 공유, 교환 또는 동기화할 필요가 있을 수 있다. 애플리케이션(108)은 공유될 데이터를 포함하는 메시지를 아이덴티티 서비스 데몬(1620)에 송신할 수 있다.

단계(1706)에서, 모바일 디바이스(100) 상의 샘플링 데몬(102)은 피어 디바이스(1600)로부터 수신된 데이터에 기초하여 메시지를 전송할지 여부를 결정할 수 있다. 예를 들어, 샘플링 데몬(102)은 로컬 승인 제어 체크 및 원격 승인 제어 체크를 수행하여 메시지가 현재 시간에 피어 디바이스(1600)로 송신되어야 하는지 여부를 결정할 수 있다. 피어 디바이스(1600)로부터 수신된 속성 이벤트 예측이 피어 디바이스(1600)의 사용자가 현재 시간에 애플리케이션(1608)을 호출할 가능성이 있음을 나타내는 경우 그리고 이벤트 데이터가 피어 디바이스(1600)의 상태들(예를 들어, 배터리 상태, 열 레벨 등)이 피어 디바이스(1600)와의 통신을 개시하는 것이 배터리를 고갈시키거나 열 상태를 악화시키지 않을 것임을 나타내는 경우, 샘플링 데몬(102)은 메시지의 전송을 승인할 수 있다.

단계(1708)에서, 샘플링 데몬(102)이 승인 제어를 수행하고 피어 디바이스(1600)와의 통신을 개시하는 것을 승인하면, 아이덴티티 서비스 데몬(1620)은 메시지를 피어 디바이스(1600)에 전송할 수 있다. 예를 들어, 아이덴티티 서비스 데몬(1620)은 메시지를 피어 디바이스(1600)의 아이덴티티 서비스 데몬(1610)에 전송할 수 있다. 이어서, 아이덴티티 서비스 데몬(1610)은, 애플리케이션(108) 및 애플리케이션(1608)이 데이터를 동기화할 수 있도록 애플리케이션(1608)에 메시지를 전송할 수 있다.

예시적인 시스템 아키텍처

도 18은 도 1 내지 도 17의 특징부들 및 프로세스들을 구현할 수 있는 예시적인 컴퓨팅 디바이스(1800)의 블록도이다. 컴퓨팅 디바이스(1800)는 예를 들어, 스마트폰, 태블릿 컴퓨터, 랩톱 컴퓨터, 웨어러블 디바이스(예를 들어, 시계), 셋톱 박스, 또는 차량 미디어 시스템일 수 있다. 컴퓨팅 디바이스(1800)는 메모리 인터페이스(1802), 하나 이상의 데이터 프로세서, 이미지 프로세서 및/또는 중앙 처리 유닛(1804), 및 주변기기 인터페이스(1806)를 포함할 수 있다. 메모리 인터페이스(1802), 하나 이상의 프로세서(1804) 및/또는 주변기기 인터페이스(1806)는 별도의 컴포넌트들일 수 있거나 하나 이상의 집적회로에 통합될 수 있다. 컴퓨팅 디바이스(1800) 내의 다양한 컴포넌트들은 하나 이상의 통신 버스 또는 신호 라인들에 의해 결합될 수 있다.

센서, 디바이스 및 서브시스템은 다수의 기능들을 용이하게 하기 위하여 주변기기 인터페이스(1806)에 결합될 수 있다. 예를 들어, 모션 센서(1810), 광 센서(1812) 및 근접 센서(1814)는 배향, 조명 및 근접 기능들을 용이하게 하기 위하여 주변기기 인터페이스(1806)에 결합될 수 있다. 다른 센서(1816)들이 또한 GNSS(global navigation satellite system)(예를 들어, GPS 수신기), 온도 센서, 생체인식 센서, 자력계 또는 다른 감지 디바이스와 같은 주변기기 인터페이스(1806)에 연결되어 관련 기능들을 용이하게 할 수 있다.

카메라 서브시스템(1820) 및 광학 센서(1822), 예를 들어, CCD(charged coupled device) 또는 CMOS(complementary metal-oxide semiconductor) 광학 센서는 사진 및 비디오 클립의 녹화와 같은 카메라의 기능들을 용이하게 하도록 이용될 수 있다. 카메라 서브시스템(1820) 및 광학 센서(1822)는, 예를 들어, 안면 인식 분석을 수행함으로써, 사용자의 인증 동안에 사용될 사용자의 이미지를 수집하는 데 사용될 수 있다.

통신 기능들은 무선 주파수 수신기와 송신기 및/또는 광학(예를 들어, 적외선) 수신기와 송신기를 포함할 수 있는, 하나 이상의 무선 통신 서브시스템(1824)을 통하여 용이하게 될 수 있다. 통신 서브시스템(1824)의 특정 설계 및 구현은 컴퓨팅 디바이스(1800)가 동작하도록 의도되는 통신 네트워크(들)에 의존할 수 있다. 예를 들어, 컴퓨팅 디바이스(1800)는 GSM 네트워크, GPRS 네트워크, EDGE 네트워크, Wi-Fi 또는 WiMax 네트워크, 및 블루투스™ 네트워크를 통해 동작하도록 설계된 통신 서브시스템들(1824)을 포함할 수 있다. 특히, 무선 통신 서브시스템들(1824)은 디바이스(100)가 다른 무선 디바이스들에 대한 기지국으로서 구성될 수 있도록 호스팅 프로토콜들을 포함할 수 있다.

오디오 서브시스템(1826)은 화자 인식, 음성 복제, 디지털 녹음, 및 전화 통신 기능과 같은 음성 지원 기능들을 용이하게 하기 위해 스피커(1828) 및 마이크로폰(1830)에 결합될 수 있다. 오디오 서브시스템(1826)은 예를 들어 음성 명령, 성문 감정(voiceprinting) 및 음성 인증의 처리를 용이하게 하도록 구성될 수 있다.

I/O 서브시스템(1840)은 터치 표면 제어기(1842) 및/또는 다른 입력 제어기(들)(1844)를 포함할 수 있다. 터치 표면 제어기(1842)는 터치 표면(1846)에 결합될 수 있다. 터치 표면(1846)과 터치 표면 제어기(1842)는, 예를 들어, 용량성, 저항성, 적외선 및 표면 탄성파(surface acoustic wave) 기술들뿐만 아니라, 터치 표면(1846)과의 하나 이상의 접촉점을 결정하기 위한 다른 근접 센서 어레이들 또는 다른 요소들을 포함하지만 이들로 제한되지 않는 복수의 터치 감응성 기술들 중 임의의 기술을 사용하여 접촉 및 이동 또는 그의 중단을 검출할 수 있다.

기타 입력 제어기(들)(1844)는 하나 이상의 버튼들, 로커 스위치(rocker switch), 지동륜(thumb-wheel), 적외선 포트, USB 포트, 및/또는 포인터 디바이스, 예컨대 스타일러스와 같은 기타 입력/제어 디바이스들(1848)에 결합될 수 있다. 하나 이상의 버튼(도시되지 않음)은 스피커(1828) 및/또는 마이크로폰(1830)의 음량 제어를 위한 상/하 버튼을 포함할 수 있다.

하나의 구현에서, 제1 지속기간 동안의 버튼 누름은 터치 표면(1846)의 잠금을 결합해제할 수 있고; 제1 지속기간보다 긴 제2 지속기간 동안의 버튼 누름은 컴퓨팅 디바이스(1800)에 대한 전력을 켜거나 끌 수 있다. 제3 지속기간 동안의 버튼 누름은, 사용자가 마이크로폰(1830)에 명령을 말하여 디바이스가 음성 명령을 실행하게 할 수 있는, 음성 제어, 또는 음성 명령, 모듈을 활성화시킬 수 있다. 사용자는 버튼들 중 하나 이상의 버튼의 기능을 사용자 지정(customize)할 수 있다. 터치 표면(1846)은 또한, 예를 들어, 가상 또는 소프트 버튼들 및/또는 키보드를 구현하는 데 사용될 수 있다.

일부 구현들에서, 컴퓨팅 디바이스(1800)는 MP3, AAC, 및 MPEG 파일들과 같은 레코딩된 오디오 및/또는 비디오 파일들을 제시할 수 있다. 일부 구현들에서, 컴퓨팅 디바이스(1800)는 iPod™와 같은 MP3 재생기의 기능을 포함할 수 있다.

메모리 인터페이스(1802)는 메모리(1850)에 결합될 수 있다. 메모리(1850)는 고속 랜덤 액세스 메모리 및/또는 비휘발성 메모리, 예컨대 하나 이상의 자기 디스크 저장 디바이스, 하나 이상의 광학 저장 디바이스, 및/또는 플래시 메모리(예를 들어, NAND, NOR)를 포함할 수 있다. 메모리(1850)는 운영 체제(1852), 예컨대 다윈(Darwin), RTXC, 리눅스(LINUX), 유닉스(UNIX), OS X, 윈도우즈(WINDOWS), 또는 임베디드 운영 체제, 예컨대 VxWorks를 저장할 수 있다.

운영 체제(1852)는 기본 시스템 서비스들을 취급하고 하드웨어 의존형 태스크들을 수행하기 위한 명령어들을 포함할 수 있다. 일부 구현들에서, 운영 체제(1852)는 커널(예를 들어, 유닉스 커널)일 수 있다. 일부 구현들에서, 운영 체제(1852)는 사용자 활동에 기초하여 모바일 디바이스의 동적 조정을 수행하기 위한 명령어들을 포함할 수 있다. 예를 들어, 운영 체제(1852)는 도 1 내지 도 17을 참조하여 설명한 바와 같이 동적 조정 특징부들을 구현할 수 있다.

메모리(1850)는 또한 하나 이상의 추가 디바이스, 하나 이상의 컴퓨터 및/또는 하나 이상의 서버와의 통신을 용이하게 하는 통신 명령어들(1854)을 저장할 수 있다. 메모리(1850)는 그래픽 사용자 인터페이스 처리를 용이하게 하는 그래픽 사용자 인터페이스 명령어들(1856); 센서 관련 처리 및 기능들을 용이하게 하는 센서 처리 명령어들(1858); 전화 관련 프로세스들 및 기능들을 용이하게 하는 전화 명령어들(1860); 전자 메시징 관련 프로세스들 및 기능들을 용이하게 하는 전자 메시징 명령어들(1862); 웹 브라우징 관련 프로세스들 및 기능들을 용이하게 하는 웹 브라우징 명령어들(1864); 미디어 처리 관련 프로세스들 및 기능들을 용이하게 하는 미디어 처리 명령어들(1866); GNSS 및 내비게이션 관련 프로세스들 및 명령어들을 용이하게 하는 GNSS/내비게이션 명령어들(1868); 및/또는 카메라 관련 프로세스들 및 기능들을 용이하게 하는 카메라 명령어들(1870)을 포함할 수 있다.

메모리(1850)는 도 1 내지 도 17을 참조하여 설명한 바와 같이 동적 조정 프로세스들 및 기능들과 같은 기타 프로세스들 및 기능들을 용이하게 하는 다른 소프트웨어 명령어들(1872)을 저장할 수 있다.

메모리(1850)는 또한 웹 비디오 관련 프로세스들 및 기능들을 용이하게 하는 웹 비디오 명령어들과 같은 기타 소프트웨어 명령어들(1874); 및/또는 웹 쇼핑 관련 프로세스들 및 기능들을 용이하게 하는 웹 쇼핑 명령어들을 저장할 수 있다. 일부 구현들에서, 미디어 처리 명령어들(1866)은 오디오 처리 관련 프로세스들 및 기능들과 비디오 처리 관련 프로세스들 및 기능들을 각각 용이하게 하는 오디오 처리 명령어들과 비디오 처리 명령어들로 나뉜다.

앞서 확인된 명령어들 및 애플리케이션들 각각은 전술한 하나 이상의 기능을 수행하기 위한 명령어들의 세트에 대응할 수 있다. 이들 명령어는 별개의 소프트웨어 프로그램들, 절차들, 또는 모듈들로서 구현될 필요는 없다. 메모리(1850)는 추가의 명령어들 또는 더 적은 수의 명령어들을 포함할 수 있다. 또한, 컴퓨팅 디바이스(1800)의 다양한 기능들은, 하나 이상의 신호 처리 및/또는 ASIC(application specific integrated circuit)를 포함하는, 하드웨어 및/또는 소프트웨어로 구현될 수 있다.

일부 실시예들에서, 컴퓨터 판독가능 저장 디바이스, 매체, 및 메모리는 비트 스트림 등을 포함하는 케이블 또는 무선 신호를 포함할 수 있다. 그러나, 언급될 때, 비일시적 컴퓨터 판독가능 저장 매체들은 에너지, 반송파 신호들, 전자기파들, 및 신호들 그 자체와 같은 매체들을 분명하게 배제한다.

다양한 예들 및 다른 정보가 첨부된 청구범위의 범주 내의 양태들을 설명하기 위해 사용되었지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 이 예들을 사용하여 다양한 구현들을 도출할 수 있을 것이므로, 그러한 예들 내의 특정 특징들 또는 배열들에 기초하여 청구범위의 어떠한 제한도 암시되어서는 안된다. 또한 그리고 비록 일부 주제가 구조적 특징들 및/또는 방법 단계들의 예들에 대해 특정한 언어로 기술되었을지라도, 첨부된 청구범위에 정의된 주제는 반드시 이러한 설명된 특징들 또는 동작들로 제한되지는 않는다는 것이 이해되어야 한다. 예를 들어, 이러한 기능은 본 명세서에서 확인된 것들 이외의 컴포넌트들에서 수행되거나 다르게 분포될 수 있다. 오히려, 설명된 특징들 및 단계들은 첨부된 청구범위의 범주 내에 있는 시스템들 및 방법들의 컴포넌트들의 예들로서 개시된다.

Claims

방법으로서,
모바일 디바이스에서, 피어 디바이스로부터 속성 이벤트 데이터를 수신하는 단계 - 상기 속성 이벤트 데이터는 상기 피어 디바이스 상에서 발생한 이벤트들을 설명함 - ;
상기 모바일 디바이스에 상기 속성 이벤트 데이터를 저장하는 단계;
상기 모바일 디바이스 상의 애플리케이션으로부터 상기 피어 디바이스와 통신하기 위한 요청을 수신하는 단계 - 상기 요청은 값을 갖는 속성을 포함하고, 상기 값은 상기 피어 디바이스 상의 대응하는 애플리케이션에 대한 식별자에 대응함 - ; 및
상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 저장된 상기 피어 디바이스에 대한 애플리케이션 개시 예측에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하는 단계를 포함하고,
상기 애플리케이션 개시 예측은 상기 대응하는 애플리케이션이 현재 기간 내에 상기 피어 디바이스 상에서 호출될 가능성을 나타내는, 방법.
제1항에 있어서, 상기 피어 디바이스 및 상기 모바일 디바이스는 단일 사용자에 의해 소유되는, 방법.
삭제
제1항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하는 단계는, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 배터리 상태를 결정하는 단계를 포함하는, 방법.
제1항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하는 단계는, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 열 상태(thermal status)를 결정하는 단계를 포함하는, 방법.
제1항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하는 단계는, 사용자가 현재 시간에 상기 피어 디바이스 상의 상기 대응하는 애플리케이션을 호출할 가능성이 있다고 결정하는 단계를 포함하는, 방법.
하나 이상의 명령어들의 시퀀스를 포함하는 비일시적 컴퓨터 판독가능 매체로서, 상기 명령어들은, 하나 이상의 프로세서에 의해 실행될 때,
모바일 디바이스에서, 피어 디바이스로부터 속성 이벤트 데이터를 수신하고 - 상기 속성 이벤트 데이터는 상기 피어 디바이스 상에서 발생한 이벤트들을 설명함 - ;
상기 모바일 디바이스에 상기 속성 이벤트 데이터를 저장하고;
상기 모바일 디바이스 상의 애플리케이션으로부터 상기 피어 디바이스와 통신하기 위한 요청을 수신하고 - 상기 요청은 값을 갖는 속성을 포함하고, 상기 값은 상기 피어 디바이스 상의 대응하는 애플리케이션에 대한 식별자에 대응함 - ;
상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 저장된 상기 피어 디바이스에 대한 애플리케이션 개시 예측에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하며,
상기 애플리케이션 개시 예측은 상기 대응하는 애플리케이션이 현재 기간 내에 상기 피어 디바이스 상에서 호출될 가능성을 나타내는, 비일시적 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 피어 디바이스 및 상기 모바일 디바이스는 단일 사용자에 의해 소유되는, 비일시적 컴퓨터 판독가능 매체.
삭제
제7항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 배터리 상태를 결정하게 하는 명령어들을 포함하는, 비일시적 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 열 상태를 결정하게 하는 명령어들을 포함하는, 비일시적 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 사용자가 현재 시간에 상기 피어 디바이스 상의 상기 대응하는 애플리케이션을 호출할 가능성이 있다고 결정하게 하는 명령어들을 포함하는, 비일시적 컴퓨터 판독가능 매체.
시스템으로서,
하나 이상의 프로세서; 및
하나 이상의 명령어들의 시퀀스를 포함하는 비일시적 컴퓨터 판독가능 매체를 포함하며, 상기 명령어들은, 상기 하나 이상의 프로세서에 의해 실행될 때,
모바일 디바이스에서, 피어 디바이스로부터 속성 이벤트 데이터를 수신하고 - 상기 속성 이벤트 데이터는 상기 피어 디바이스 상에서 발생한 이벤트들을 설명함 - ;
상기 모바일 디바이스에 상기 속성 이벤트 데이터를 저장하고;
상기 모바일 디바이스 상의 애플리케이션으로부터 상기 피어 디바이스와 통신하기 위한 요청을 수신하고 - 상기 요청은 값을 갖는 속성을 포함하고, 상기 값은 상기 피어 디바이스 상의 대응하는 애플리케이션에 대한 식별자에 대응함 - ;
상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 저장된 상기 피어 디바이스에 대한 애플리케이션 개시 예측에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하며,
상기 애플리케이션 개시 예측은 상기 대응하는 애플리케이션이 현재 기간 내에 상기 피어 디바이스 상에서 호출될 가능성을 나타내는, 시스템.
제13항에 있어서, 상기 피어 디바이스 및 상기 모바일 디바이스는 단일 사용자에 의해 소유되는, 시스템.
삭제
제13항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 배터리 상태를 결정하게 하는 명령어들을 포함하는, 시스템.
제13항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스의 열 상태를 결정하게 하는 명령어들을 포함하는, 시스템.
제13항에 있어서, 상기 모바일 디바이스에 의해, 상기 속성 이벤트 데이터에 기초하여 상기 피어 디바이스와의 통신을 개시할 것을 결정하게 하는 명령어들은, 사용자가 현재 시간에 상기 피어 디바이스 상의 상기 대응하는 애플리케이션을 호출할 가능성이 있다고 결정하게 하는 명령어들을 포함하는, 시스템.