KR102280465B1 - 단말 및 그 단말에서 애플리케이션 동기화 방법 - Google Patents

Abstract

본 명세서는 애플리케이션 방법 및 장치에 관한 것으로, 본 명세서의 일 실시 예에 따르는 단말의 애플리케이션 동기화 방법은, 제1 알람 등록 요청을 수신하는 단계, 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는지 판단하는 단계 및 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는 경우 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 주기 추정을 수행하고 상기 주기 추정의 결과에 따라 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 수행 시점을 조정하는 조정 단계를 포함할 수 있다.

Description

단말 및 그 단말에서 애플리케이션 동기화 방법 {A terminal and application synchronization method thereof}

본 명세서는 애플리케이션 관리 방법에 관한 것으로, 더욱 상세하게는 애플리케이션의 동기화에 관한 것이다.

이동 통신 기술이 발전해감에 따라 단말은 기존의 음성 통화 기능뿐만 아니라 다양한 데이터 통신 기능을 수행할 수 있게 되었다. 특히 스마트 폰과 같은 단말과 전송 속도가 향상된 네트워크가 개발됨에 따라, 사용자들은 다양한 데이터를 시간, 장소 등에 구애 받지 않고 송수신할 수 있게 되었다.

스마트 폰과 같은 단말은 메일 클라이언트, SNS(Social Network Service) 클라이언트, IM(Instant Messaging) 클라이언트 등의 다양한 애플리케이션들이 구동된다. 이와 같은 애플리케이션들은 네트워크와 연결하여 애플리케이션이 보유한 데이터와 상대방(서버)가 보유한 데이터를 동기화할 수 있다. 그러기 위해 각 애플리케이션들은 사용자의 선호에 따라 설정된 적절한 값의 데이터 동기화 주기에 따라 운용된다. 일반적으로 설정되는 동기화 주기는 5분, 15분, 30분, 1시간, 4시간 등이지만, 사용자의 취향에 따라 동기화 주기의 값은 다양한 값으로 설정될 수 있다. 애플리케이션의 동기화 주기를 설정할 때, 실시간적으로 업데이트되는 데이터를 받기를 원하는 사용자는 동기화 주기를 짧은 값으로 설정한다. 반대로, 실시간적 업데이트가 요구되지 않고, 통신 자원 및 배터리를 절약하고자 하는 경우에는 사용자는 동기화 주기를 긴 값으로 설정할 수 있다.

그리고 단말은 해당 애플리케이션에 대해 설정된 동기화 주기마다 네트워크 상의 상대방(보통은 서버)에게로 업데이트된 데이터를 요청하는 요청 메시지를 송신한다. 그러면 해당 상대방은 요청된 데이터를 단말에게 송신한다.

단말은 특별히 통신이 요구되는 상황이 아니면 전력 소비를 줄이기 위해 절전 모드(IDLE)로 설정된다. 각각의 애플리케이션이 업데이트를 수행할 때마다, 단말은 절전 모드로부터 최대 동작 모드(ACTIVE)로 전환된다. 따라서 복수의 애플리케이션에 대해 각 애플리케이션을 위한 동기화 주기가 설정되어 있는 경우, 절전 모드에서 최대 동작 모드로 전환되는 횟수가 많아진다. 마찬가지로, 하나의 애플리케이션에 대해서 둘 이상의 동기화 반복 작업이 설정되고 각 동기화 작업의 주기가 서로 다르다면 둘 이상의 애플리케이션의 동기화 반복 작업과 마찬가지 문제가 발생할 수 있다.

도 1은 종래 기술에 따르는 동기화 과정을 도시한 도면이다.

메일 클라이언트에 계정(A), 계정(B) 및 계정(C)가 등록돼 있다. 각 계정에 대해 15분 단위로 주기적으로 동기화 작업을 수행하도록 설정돼 있다. 3600초에 계정(A)에 대해서 동기화 작업이 시작되고, 3605초에 동기화 작업이 완료된다. 완료 시점을 기준으로 15분 후에 계정(A)에 대한 동기화 작업이 진행되도록 알람이 등록된다. 이후 4505초에 계정(A)에 대한 동기화 작업이 다시 수행된다. 계정(B), (C)에 대해서도 비슷한 동작이 수행된다.

계정(A)에 대한 첫 번째 동기화 작업이 3605초에 종료된 후 8초 뒤에 계정(B)에 대한 동기화 작업이 다시 시작된다. 한 애플리케이션, 즉 메일 클라이언트에 대한 전체 동기화 과정을 살펴보면, 각 동기화 작업들 사이에 쉬는 시간은 8초, 5초, 14분 35초, 10초, 14분 33초 등이 된다.

이와 같이 종래 기술에 따르면, 메일 클라이언트에 여러 개의 계정을 등록하고 각 계정마다 별도의 동기화 주기를 설정하여 운용하는 경우에는 각 계정에 대해 서로 다른 시점에서 동기화를 수행한다. 그러므로 해당 단말의 한 애플리케이션(메일 클라이언트)에 대해서 발생하는 동기화 전체를 살펴보면 동기화 작업이 불규칙하게, 비주기적으로 발생한다. 이로 인해 매 동기화 실행 시마다 단말은 절전 모드(IDLE)로부터 최대 동작 모드(ACTIVE)로 전환된다. 이러한 전환 횟수가 많을수록 모드 전환을 위한 과정에서 소요되는 시그널링 및 이에 의한 전력 소모 등이 불필요하게 발생한다. 예를 들어, 3G(3^rd Generation) WCDMA(Wideband Code Division Multiple Access) 시스템에서 보존 모드(Preservation mode) 천이 및 RAB(Radio Access Bearer) 재설정을 위해 35개의 제어메시지가 소요된다.

본 명세서의 일부 실시 예는 효율적으로 애플리케이션 동기화를 수행하기 위한 것이다.

본 명세서의 일부 실시 예는 강건하게 애플리케이션 동기화를 수행하기 위한 것이다.

본 명세서의 일 실시 예에 따르는 단말의 애플리케이션 동기화 방법은, 제1 알람 등록 요청을 수신하는 단계, 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는지 판단하는 단계 및 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는 경우 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 주기 추정을 수행하고 상기 주기 추정의 결과에 따라 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 수행 시점을 조정하는 조정 단계를 포함할 수 있다.

본 명세서의 일 실시 예에 따르는 애플리케이션의 동기화를 수행하는 단말은, 제1 알람 등록 요청을 수신하고, 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는지 판단하고, 상기 제1 알람 등록 요청의 트리거 시점 이후 미리 설정된 시간 이내에 상기 제1 알람 등록 요청에 상응하는 애플리케이션의 데이터 송수신 관련 동작이 감지되는 경우 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 주기 추정을 수행하고 상기 주기 추정의 결과에 따라 상기 제1 알람 등록 요청에 연관된 반복 동기화 작업의 수행 시점을 조정하는 제어부 및 상기 제어부의 제어에 따라 데이터를 송수신하는 통신부를 포함할 수 있다.

본 명세서의 일부 실시 예에 따르면 효율적으로 애플리케이션 동기화를 수행할 수 있다.

본 명세서의 일부 실시 예에 따르면 강건하게 애플리케이션 동기화를 수행할 수 있다.

도 1은 종래 기술에 따르는 동기화 과정을 도시한 도면이다.
도 2는 본 명세서의 일 실시 예에 따르는 단말(200)의 블록구성도이다.
도 3은 본 명세서의 제1 실시 예에 따르는 제어부(220)의 운영 체제 구성을 도시한 도면이다.
도 4는 본 명세서의 일 실시 예에 따른 알람 리스트의 구성을 도시한 도면이다.
도 5는 본 명세서의 일 실시 예에 따르는 동기화 과정을 도시한 도면이다.
도 6은 본 명세서의 일 실시 예에 따르는 동기화 주기 추정 과정의 순서도이다.
도 7은 본 명세서의 일 실시 예에 따르는 알람 설정 과정의 순서도이다.
도 8은 본 명세서의 제2 실시 예에 따르는 단말의 운영 체제 구성도이다.
도 9는 본 명세서의 제2 실시 예에 따르는 단말의 동작을 나타낸다.
도 10은 본 명세서의 제2 실시 예에 따르는 스크린 ON/OFF에 관한 상태 보고 과정의 순서도이다.
도 11은 본 명세서의 제2 실시 예에 따르는 소켓 활동 보고 과정의 순서도이다.
도 12은 본 명세서의 제2 실시 예에 따르는 데이터 활동 보고 과정의 순서도이다.
도 13은 본 명세서의 제2 실시 예에 따르는 패키지 활동 보고 과정의 순서도이다.
도 14는 본 명세서의 제2 실시 예에 따르는 단말의 OS 구성을 도시한다.
도 15 및 도 16은 본 명세서의 제2 실시 예에 따르는 트리거 시각 조정 과정을 나타낸다.
도 17 및 도 19는 본 명세서의 제2 실시 예에 따르는 목록 관리 방식을 나타낸다.
도 18은 본 명세서의 제2 실시 예에 따르는 목록 관리 과정의 순서도이다.
도 20은 본 발명에 따른 애플리케이션 동기화 관리 방법의 일실시예의 수행과정을 도시한 도면이다.
도 21은 본 발명에 따른 알람 판별 방법의 일실시예의 수행과정을 도시한 도면이다.
도 22 및 23은 본 발명에 따른 이상 동작 판별 방법의 일실시예의 수행과정을 도시한 도면이다.
도 24은 본 발명에 따른 이상 동작 판별 방법의 다른 실시예의 수행과정을 도시한 도면이다.

이하, 본 명세서의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.

실시 예를 설명함에 있어서 본 명세서가 속하는 기술 분야에 익히 알려져 있고 본 명세서와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 명세서의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.

마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.

본 명세서에서 하나의 동기화 작업은 일회적 동기화 작업을 일컫는다. 예를 들어 도 1에서 3600초에 시작해서 3605초에 종료되는 계정(A)에 대한 동기화 작업은 하나의 동기화 작업이다.

본 명세서에서 반복 동기화 작업은 반복되는 일회적 동기화 작업의 집합체를 일컫는다. 예를 들어 계정(A)에 대한 동기화 작업은 대략 15분 간격으로 반복되며, 이러한 식으로 반복되는 동기화 작업을 하나의 반복 동기화 작업으로 취급한다. 계정(A)에 대한 동기화 작업의 집합은 하나의 반복 동기화 작업이 된다. 계정(B)에 대한 동기화 작업의 집합은 다른 하나의 반복 동기화 작업이 된다. 각 반복 동기화 작업은 대응되는 식별자를 가진다.

도 2는 본 명세서의 일 실시 예에 따르는 단말(200)의 블록구성도이다.

도 2를 참조하면 본 명세서의 일 실시 예에 따르는 단말(200)은 통신부(210), 제어부(220) 및 저장부(230)를 포함할 수 있다. 제어부(220)는 단말(200)이 후술하는 실시 예들 중 어느 하나에 따라 동작하도록 단말(200)의 전반적인 동작을 제어한다. 특히 제어부(220)는 후술하는 실시 예 중 어느 하나의 방식에 따라 각 반복 동기화 작업의 주기를 추정하고 그에 따라 동기화 작업의 시작 시점을 조정할 수 있다. 제어부(220)는 동기화 작업의 시작 시점 조정에 필요한 데이터를 저장부(230)에 저장한다. 통신부(210)는 제어부(220)의 제어에 따라 네트워크 상의 서버 기타 상대방 엔티티와 통신을 수행하여 동기화 작업에 필요한 데이터 및/또는 신호를 송수신한다.

도 2에 도시되지는 않았으나, 단말(200)은 사용자의 키입력, 터치입력을 수신하는 입력부 및/또는 사용자에게 정보를 표시/제공하는 표시부를 더 포함할 수 있다.

도 2의 각 구성부의 구체적인 동작은 도 3 내지 도 19를 참조하여 상세히 후술한다.

도 3은 본 명세서의 제1 실시 예에 따르는 제어부(220)의 운영 체제 구성을 도시한 도면이다.

도 3을 참조하면, 제어부(220)의 운영체제는 애플리케이션(Application) 계층 (310), 애플리케이션 프레임 워크(Application Framework) 계층(320), 시스템 라이브러리(system library) 계층(330) 및 커널(Kernel) 계층(340)을 포함한다.

애플리케이션 계층(310)은 애플리케이션(315)이 동작하는 계층이다. 애플리케이션 프레임 워크 계층(320)은 특정 운영체제를 위한 응용 프로그램 표준 구조를 구현하는 클래스와 라이브러리의 집합이다. 즉 애플리케이션 프레임 워크 계층(320)은 애플리케이션(315)의 라이프-사이클을 관리하며, 이벤트 처리 및 애플리케이션의 제어 기능을 제공한다. 여기서 애플리케이션 프레임 워크 계층(320)은 애플리케이션(315)의 업데이트 주기를 동기화를 요청하는 알람 관리자(325)를 포함할 수 있다.

시스템 라이브러리 계층(330)은 운영체계의 부분들이 기억되어 있는 데이터 세트 및 파일들의 집합이다. 여기서 시스템 라이브러리 계층(330)은 애플리케이션 계층(310)이 수행하는 애플리케이션(315)의 동기화 주기를 동기화하는 동기화 스케줄러(335)를 포함한다.

커널 계층(340)은 인터럽트 처리, 프로세스 관리, 메모리 관리, 시스템 관리, 프로그래밍 인터페이스를 제공하며, 운영체계에서 기본적인 기능을 제공하는 핵심이다. 그래서 커널(340)은 일반적으로 접근이 불가능한 메모리에 로드된다. 즉 커널은 하드웨어를 제어하기 위한 일종의 애플리케이션이라고 볼 수 있다.

이와 같은 계층으로 구성된 제어부(220)의 동작 과정은 다음과 같다.

애플리케이션 계층(310)은 우선 등록되는 애플리케이션(315)의 동기화 작업에 대하여 350단계에서 동기화 주기를 등록하기 위한 동기화 주기 등록 요청을 애플리케이션 프레임 워크 계층(320)의 알람 관리자(325)에게 송신한다. 그러면 알람 관리자(325)는 355단계에서 동기화 스케줄러(335)에게 알람 리스트에 알람 항목을 추가할 것을 요청한다. 이와 같은 과정은 동기화 작업이 등록될 때마다, 반복적으로(357) 수행된다.

그러면 동기화 스케줄러(335)의 최적 동기화 산출부(360)는 후술하는 실시 예에 따라 요청된 동기화 작업이 연관된 반복 동기화 작업의 동기화 주기를 산출하고, 363단계에서 산출된 동기화 주기를 알람 리스트(365)에 추가한다. 그리고 동기화 스케줄러(335)는 367단계에서 알람 리스트에 저장된 스케줄링 동기화 주기를 확인하고, 알람 처리부(370)는 알람을 애플리케이션 계층(310)에게 알리기 위한 알람 주기를 확인한다. 만약 알람 주기가 되면, 동기화 스케줄러(335)는 375단계에서 애플리케이션의 동기화 알람을 애플리케이션단(310)에 알린다.

최적 동기화 산출부(360)는 여러 동기화 작업들이 동일 시점에 수행되거나, 또는 연속적으로 수행되도록 동기화 작업들의 수행 시점을 조정할 수 있다.

최적 동기화 산출부(360)는 동기화 스케줄러(335)를 구성하는 구성요소가 될 수도 있고, 최적 동기화 산출부(360)는 동기화 스케줄러(335) 외부의 별도의 구성요소가 될 수도 있다.

도 4는 본 명세서의 일 실시 예에 따른 알람 리스트의 구성을 도시한 도면이다.

도 4를 참조하면, 저장부(230)에 저장되는 알람 리스트는 각 반복 동기화 작업에 대해 대응되는 레코드(410)를 포함한다. 하나의 반복 동기화 작업에 대해 하나의 레코드(410)가 대응된다. 각 레코드는 타입(type; 415), 시작 시점(when; 417), 스케줄링 동기화 주기(Repeat Interval; 419) 필드를 포함할 수 있다. 여기서 타입(415)은 업데이트 주기를 알리는 알람을 설정하는 방법에 대한 정보를 포함하며, 알람을 설정할 때, 절대적인 시간(UTC)을 기준으로 할 것인지, 아니면 상대적인 시간(5분, 10분 후 등)을 기준으로 할 것인지를 알리는 정보이다. 그리고 단말에서 사용되는 타입(415)으로 ELAPSED_REALTIME_WAKEUP, RTC_WAKEUP과 같은 정보가 대표적이다. ELAPSED_REALTIME_WAKEUP은 단말의 시스템 시간을 이용하여 알람을 트리거할지를 결정하는 정보로, 현재 시간을 기준으로 시간이 얼마나 지난 후 동작할 것인지를 결정하는 정보이다. RTC_WAKEUP은 네트워크를 통해 획득된 시간으로 알람을 트리거할지를 결정하는 정보로, 절대적인 시간을 기준으로 한다.

시작 시점(417)은 반복 동기화 작업이 등록된 다음 처음 동기화를 수행할 시간을 의미한다. 그리고 반복 주기(419)는 해당 반복 동기화 작업의 주기에 대한 정보이다.

각 레코드(410)는 그 레코드(410)에 대응되는 반복 동기화 작업을 식별할 수 있도록 하는 식별자를 포함할 수 있다. 또한 각 레코드(410)는 후술하는 바와 같이 해당 반복 동기화 작업의 마지막 동기화 시점이 저장될 수 있다.

변형 예에 따르면 도 4와 같이 모든 필드가 하나의 레코드에 저장되는 대신, 일부 필드가 다른 레코드에 저장될 수 있다. 이 경우 동일한 반복 동기화 작업 식별자를 가지는 두 레코드를 합쳐서 도 4와 동일한 레코드를 이용한 것과 동일한 효과를 얻을 수 있다.

여러 개의 반복 동기화 작업을 운용하는 애플리케이션(315)은 각각의 동기화 작업이 필요할 때 마다 동기화 작업을 위한 알람 등록 요청을 동기화 스케줄러(335)에게 전달한다. 알람 등록 요청은 주기 정보를 포함하고 있지 않으며, 각 알람 등록 요청은 그에 상응하는 반복 동기화 작업을 식별하는 식별자를 포함한다. 동기화 스케줄러(335)는 나중에 알람의 시점이 되면 아래 표 1과 같은 정보를 포함하는 동기화 작업 시작 알림(notification)을 애플리케이션(315)에게 제공한다. 동기화 작업 시작 알림은 알람 알림이라고도 칭한다.

알람 대상 반복 동기화 작업 식별자
동기화 상태 정보(Sync Status Info)
	제1 반복 동기화 작업 식별자	제1 마지막 동기화 시간
	제2 반복 동기화 작업 식별자	제2 마지막 동기화 시간
	제3 반복 동기화 작업 식별자	제3 마지막 동기화 시간
	...	...

알람 대상 반복 동기화 작업 식별자는 이전의 등록에 따라 현재 동기화 시점이 도래한 반복 동기화 작업의 식별자이다. 즉, 애플리케이션(315)은 표 1의 알림을 수신하면, 알람 대상 반복 동기화 작업 식별자에 해당하는 동기화 작업을 수행하면 된다. 예를 들어 메일 클라이언트 애플리케이션의 경우 특정 계정에 대한 반복 동기화 작업은 하나의 반복 동기화 작업 식별자를 이용해 식별될 수 있다. 다른 계정에 대한 반복 동기화 작업은 다른 반복 동기화 작업 식별자를 가질 것이다.

추가로 표 1의 알림은 알람 대상 반복 동기화 작업과 그 외의 다른 동기화 작업에 대한 정보를 포함한다. 표 1의 알림은 각 동기화 작업의 식별자와 그에 상응하는 반복 동기화 작업의 마지막 동기화 시간(예를 들어, 완료 시점)을 연관시켜 저장하고 있다. 상기 표 1의 정보는 처음 알람의 등록을 요청하는 시점에는 그 알람을 등록한 애플리케이션(315) 외에는 다른 애플리케이션이 열람할 수 없으며, 알람의 알림이 발생하여 알림이 정상적으로 완료되었다는 것을 알게 된 이후에 상기 전달된 표 1의 정보를 열람할 수 있는 특징이 있다.

도 5는 본 명세서의 일 실시 예에 따르는 동기화 과정을 도시한 도면이다.

도 5의 실시 예에서, 애플리케이션(315)은 메일 클라이언트이다. 메일 클라이언트(315)에 대해 세 개의 계정(A, B, C)이 등록돼 있다. 애플리케이션 레벨에서, 각 계정에 대해 15분 단위로 동기화를 수행하도록 설정돼 있다. 하지만 상술한 바와 같이 애플리케이션(315)이 동기화 스케줄러(335)에게 전달하는 알람 등록 요청 메시지는 주기 정보를 포함하고 있지 않다. 따라서 동기화 스케줄러(335), 또는 별도의 구성부가 각 반복 동기화 작업의 주기를 추정해낼 필요가 있다. 동기화 작업의 주기 추정 과정은 도 6을 참조하여 후술한다.

도 6은 본 명세서의 일 실시 예에 따르는 동기화 주기 추정 과정의 순서도이다.

단계 610에서 제어부(220)는 표 1과 같은 형태의, 또는 이와 유사한 정보를 가지는 동기화 작업 시작 알림을 획득한다. 동기화 작업 시작 알림은 상술한 바와 같이 해당 동기화 작업의 시작 시점에 대한 정보와 함께, 다른 동기화 작업들의 마지막 종료 시간에 대한 정보를 포함한다. 도 5의 예를 참조하면 계정(A)에 대한 동기화 작업이 3600초에 시작되어 3605초에 종료된다. 계정(A)에 대한 동기화 작업 시작 시점인 3600초에 제어부(220)는 동기화 시작 알림을 획득할 수 있다. 단계 620에서 제어부(220)는 동기화 작업 시작 알림으로부터 해당 애플리케이션의 전체 동기화 작업의 상태 정보를 획득한다. 예를 들어 제어부(220)는 동기화 작업 시작 알림으로부터 계정(A)에 대한 동기화 작업이 마지막으로 완료된 시점, 계정(B)에 대한 동기화 작업이 마지막으로 완료된 시점 및 계정(C)에 대한 동기화 작업이 마지막으로 완료된 시점에 대한 정보를 획득할 수 있다.

단계 630에서 제어부(220)는 동기화 시작 알림의 대상 반복 동기화 작업에 대한 마지막 동기화 시점의 기록이 있는지 판단한다. 제어부(220)는 표 1의 동기화 시작 알림으로부터 해당 반복 동기화 작업, 예를 들어 계정(A)에 대한 마지막 동기화 시점을 확인할 수 있다. 변형 예에 따르면 후술하는 단계 660에서 동기화 시점을 기록할 수 있고, 제어부는 이 때 기록된 동기화 시점을 이용하여 계정(A)에 대한 마지막 동기화 시점을 확인할 수도 있다. 또한 제어부(220)는 동기화 시작 알림으로부터 마지막 동기화 시점을 확인하고, 단계 660에서 기록된 마지막 동기화 시점도 확인하여 둘 중 더 늦은 동기화 시점을 취할 수도 있다. 이하에서는 동기화 시작 알림 및 단계 660에서 기록된 마지막 동기화 시점을 모두 이용하는 것으로 가정하여 설명한다.

동기화 시작 알림에 계정(A)에 대한 반복 동기화 작업의 마지막 동기화 시점이 포함돼 있지 않고, 단계 660에서 기록된 계정(A)에 대한 반복 동기화 작업의 마지막 동기화 시점도 없는 경우 과정은 단계 660으로 진행한다. 단계 660에서 제어부(660)는 계정(A)에 대한 마지막 동기화 시점을 기록한다. 여기서 마지막 동기화 시점은 해당 동기화 시작 알림이 발생한 시점, 실제로 반복 동기화 작업이 시작된 시점, 및 실제로 반복 동기화 작업이 종료된 시점 중 어느 하나가 될 수 있다. 반복 동기화 작업이 종료된 시점을 기록하는 경우 제어부(220)는 동기화 작업의 종료 시까지 대기하고 동기화 작업이 종료된 후 마지막 동기화 시점을 기록할 수 있을 것이다.

동기화 시작 알림 및, 단계 660에서 기록된 정보로부터 계정(A)에 대한 반복 동기화 작업의 마지막 동기화 시점을 획득한 경우 과정은 단계 640으로 진행한다.

단계 640에서 제어부(220)는 동기화 시작 알림의 발생 시점 및 해당 반복 동기화 작업의 마지막 동기화 시점을 이용하여 동기화 주기 추정값을 획득하고 저장한다. 예를 들어 동기화 시작 알림의 발생 시점으로부터 해당 반복 동기화 작업의 마지막 동기화 시점을 뺀 값이 해당 반복 동기화 작업의 동기화 주기 추정값이 될 수 있다. 동기화 주기 추정값은 예를 들어 도 4와 같은 레코드에 저장될 수 있다.

단계 650에서 제어부(220)는 동기화 주기 추정값을 이용해 다음 동기화 시점을 획득하고 저장한다. 예를 들어 계정 (A)에 대한 동기화 작업이 3605초에 종료되고, 동기화 주기 추정값이 15분(=900초)라면 다음 동기화 시점은 (종료시점)+(주기 추정값)=4505초가 된다. 다음 동기화 시점은 예를 들어 도 4와 같은 레코드에 저장될 수 있다. 변형 예에 따르면 (시작시점)+(주기 추정값)이 다음 동기화 시점으로 추정될 수도 있다. 이후 상술한 바와 같이 단계 660의 과정을 수행한다.

도 6의 과정을 거치면 해당 반복 동기화 작업에 대한 마지막 동기화 시점이 저장된다. 또한, 이전에 해당 반복 동기화 작업이 수행된 적이 있다면, 해당 반복 동기화 작업의 동기화 주기 추정값 및 다음 동기화 시점 추정값도 획득될 수 있다. 도 5의 실시 예에서, 3613초에 시작하는 계정 (B)의 동기화 작업 및 3625초에 시작하는 계정 (C)의 동기화 작업 모두에 대해서 동일한 과정이 수행될 수 있다.

도 6의 실시 예는 주기 추정 과정의 예시를 설명한 것이고 둘 이상의 동기화 작업 수행 시점을 획득하고 둘의 차이를 획득하는 다른 유사한 방식이 도 6의 실시 예를 대체할 수도 있다.

도 6의 실시 예에서, 동기화 작업 시작 알림만으로 주기를 추정하도록 가정하고 있으나, 도 8을 참조하면 본 명세서의 다른 실시 예에서는 동기화 작업 시작 알림과 함께 네트워크 송수신 상태를 추가로 고려하는 실시 예가 후술된다.

도 7은 본 명세서의 일 실시 예에 따르는 알람 설정 과정의 순서도이다.

단계 710에서 제어부(220)는 애플리케이션(315)으로부터 출력되는 동기화 알람의 등록 요청을 감지한다. 상술한 바와 같이 동기화 알람 요청은 주기 정보를 포함하고 있지 않으며, 반복 동기화 작업 식별자 및 동기화 시점만을 포함한다. 예를 들어 3620초에 계정 (B)에 대한 동기화 작업이 종료된 후 애플리케이션(315)은 종료 시점과 설정된 동기화 주기 15분(=900초)을 더하여 4520(=3620+900)초를 동기화 작업 시점으로 설정하여 동기화 알람의 등록 요청을 동기화 스케줄러(335)에게 송신한다.

단계 720에서 제어부(220)는 동일 애플리케이션의 다른 동기화 작업(들)의 정보를 획득한다. 예를 들어 계정(B)에 대한 반복 동기화 작업의 식별자를 가지는 동기화 작업의 알람 등록 요청이 발생한 경우를 설명한다. 이 경우 제어부(220)는 해당 반복 동기화 작업 식별자의 애플리케이션(315)의 다른 반복 동기화 작업 식별자들을 추출하고, 추출된 다른 반복 동기화 작업 식별자들의 다음 동기화 시점을 획득한다. 예를 들어 계정(B)의 동기화 작업 종료 시점 3620초에는 계정 (A)에 대한 반복 동기화 작업의 다음 동기화 작업 시점(4505초)를 획득할 수 있다. 계정(C)의 동기화 작업 종료 시점 3630초에는 계정 (A)에 대한 반복 동기화 작업의 다음 동기화 작업 시점(4505) 및 계정 (B)에 대한 반복 동기화 작업의 다음 동기화 작업 시점(4505초, 또는 4510초)를 획득할 수 있다.

단계 730에서 제어부(220)는 동기화 알람의 등록 요청의 시점, 즉, 계정 (B)에 대한 알람 등록 요청에 포함된 4520초와 계정 (A)에 대한 다음 동기화 시점(4505초)를 비교하여 그 차이가 미리 설정된 문턱값 이내인지 판단한다. 예를 들어 문턱값이 20초라면, 두 값의 차이는 문턱값(20초) 이하인 150초이므로, 과정은 단계 740으로 진행한다. 이러한 비교 과정은 동일 애플리케이션의 모든 반복 동기화 작업에 대해서 수행된다. 두 값의 차이가 문턱값보다 큰 경우 별도의 조정 없이 그대로 알람이 등록된다.

단계 740에서 제어부(220)는 등록 요청된 동기화 알람 시점을 조정한다. 제어부(220)는 예를 들어 계정(B)의 다음 동기화 알림 시점이 계정(A)의 다음 동기화 알림 시점과 동일한 4505초가 되도록 조정할 수 있다. 다만 두 동기화 작업이 동시에 수행될 수 없다면, 제어부(220)는 계정(A)에 대한 동기화 작업이 끝나는 시점(4510초)까지 기다렸다가 계정(A)에 대한 동기화 작업이 끝나면 계정 (B)에 대한 반복 동기화 작업의 알람을 애플리케이션에게 알릴 수도 있다. 제어부(220)는 기타 유사한 방식을 통해 계정 (A)에 대한 동기화 작업과 계정(B)에 대한 동기화 작업이 동시에, 또는 곧바로 이어서 (미리 설정된 시간 이내의 차이만 두고) 수행되도록 계정(B)에 대한 동기화 작업의 수행 시점을 조정할 수 있다.

단계 750에서 제어부(220)는 단계 740의 결과에 따라 동기화 주기 추정값을 조정한다. 예를 들어, 계정(B)에 대한 동기화 작업은 3620초에 완료되고, 다음 동기화 작업은 4505초에 시작되도록 설정되므로 동기화 주기 추정값은 885초(=15분-15초)가 된다. 다음 동기화 작업이 4510초에 시작되도록 설정되는 경우 동기화 주기 추정값은 890초(=15분-10초)가 된다. 조정된 동기화 주기 추정값은 저장부(230)에 도 4의 레코드와 같은 형태로 저장된다.

　

위와 같은 절차에 따르면 도 5에서 도시된 바와 같이 동일 애플리케이션에 대해 여러 개의 동기화 작업을 수행하는 경우에 제어부(220)는 각 반복 동기화 작업에 대해 설정된 동기화 주기가 약 15분 임을 학습에 의해 산출할 수 있다. 제어부(220)는 상기 산출된 동기화 작업 주기에 따라 개별 동기화 작업을 판별할 수 있으며 여러 개의 반복 동기화 작업의 시작 시점을 각각 제어하면 설정된 동기화 주기와 동일하게 또는 유사한 주기(α,β,α',β' 오차 이내)로 동기화 작업이 수행될 수 있다.

도 6 및 도 7을 참조한 실시 예에서 동일한 애플리케이션에 대한 여러 반복 동기화 작업의 실행 시점(주기)을 조정하는 방안이 제공되었다. 하지만 여러 애플리케이션이 각각 그에 상응하는 반복 동기화 작업을 가진 경우에도, 서로 다른 애플리케이션에 연관되는 반복 동기화 작업 실행 시점의 조정도 유사한 방식으로 수행될 수 있다. 이 경우 판단을 위해 수집되는 정보가 한 애플리케이션의 반복 동기화 작업들에 관한 정보에 한정되지 않고 전체 반복 동기화 작업들에 관한 정보로 확장될 수 있다.

도 8은 본 명세서의 제2 실시 예에 따르는 단말의 운영 체제 구성도이다.

도 8을 참조하면 본 명세서의 제2 실시 예에 따르는 단말의 운영 체제는 애플리케이션 계층(810), 플랫폼/프레임워크 계층(820) 및 커널 계층(830)을 포함한다.

애플리케이션 계층(810)은 애플리케이션(812)이 동작하는 계층이다. 플랫폼/프레임 워크 계층(820)은 특정 운영체제를 위한 응용 프로그램 표준 구조를 구현하는 클래스와 라이브러리의 집합이다. 즉 플랫폼프레임 워크 계층(820)은 애플리케이션(812)의 라이프-사이클을 관리하며, 이벤트 처리 및 애플리케이션의 제어 기능을 제공한다. 여기서 플랫폼/프레임 워크 계층(820)은 동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826)를 포함할 수 있다. 트래픽 모니터부(826)는 특정한 시점에, 또는 트래픽 분석부(824)의 요청에 따라 트래픽 송수신에 관련된 활동을 모니터한다. 트래픽 모니터부(826)는 모니터링된 정보를 트래픽 분석부(824)에게 제공한다. 트래픽 분석부(824)는 모니터링된 정보를 기초로 트래픽(또는 동기화 작업)의 주기성 여부를 판단하고, 트래픽의 주기에 관한 정보를 동기화 스케줄러(822)에게 제공한다. 동기화 스케줄러(822)는 트래픽의 주기에 관한 정보 및 알람 등록에 관한 정보 등을 기초로 반복 동기화 작업의 수행 시각(주기)를 조정할 수 있다. 동기화 스케줄러(822)는 반복 동기화 작업의 수행 시각을 최적으로 설정하기 위한 최적화 모듈(823)을 포함할 수 있다.

커널 계층(830)은 인터럽트 처리, 프로세스 관리, 메모리 관리, 시스템 관리, 프로그래밍 인터페이스를 제공하며, 운영체계에서 기본적인 기능을 제공하는 핵심이다. 그래서 커널(340)은 일반적으로 접근이 불가능한 메모리에 로드된다. 즉 커널은 하드웨어를 제어하기 위한 일종의 애플리케이션이라고 볼 수 있다.

본 실시 예에서, 동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826)는 모두 플랫폼/프레임 워크 계층(820)에 포함된다. 이러한 구성에 따르면 연관된 구성들이 하나의 계층에서 수행되어 개발이나 유지/보수에 편의성을 가질 수 있다. 다만, 변형 예에 따르면, 트래픽 모니터부(826)가 커널 계층(830)에 포함되거나 트래픽 모니터부(826) 및 트래픽 분석부(824)가 커널 계층(830)에 포함될 수도 있다.

동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826)는 실제로는 하나의 구성부로 구현될 수도 있다. 또는 동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826) 중 어느 두 개가 하나의 구성부로 구현될 수도 있다. 다만 이후의 명세서 기재에서는 동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826)가 서로 분리된 구성으로 구현된 것으로 가정한다. 동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826) 중 일부가 서로 병합되는 경우 구성부 사이의 신호/데이터 송수신 과정은 생략될 수 있다.

동기화 스케줄러(822), 트래픽 분석부(824) 및 트래픽 모니터부(826)의 구체적인 동작에 대해서는 도 9 내지 도 19를 참조하여 후술한다.

도 9는 본 명세서의 제2 실시 예에 따르는 단말의 동작을 나타낸다.

트래픽 모니터부(826)는 트래픽 활동(920)을 모니터한다. 트래픽 모니터부(826)는 예를 들어 장치의 ON/OFF 상태(스크린 ON/OFF 상태)를 모니터링할 수 있다. 또한 트래픽 모니터부(826)는 통신 모듈(WIFI 모듈 및/또는 LTE 모듈 등)의 데이터 활동을 모니터링할 수 있다. 특히 트래픽 모니터부(826)는 애플리케이션이 호출하는 소켓 API를 모니터링하여 데이터 송수신 시도를 파악할 수 있다.

변형 예에 따르면 트래픽 모니터부(826)는 네트워크 통계에 관한 정보를 주기적으로 획득하여 데이터 송수신을 모니터링할 수 있다. 최근의 안드로이드 OS는 각 애플리케이션에 의하여 수행된 데이터 송수신 누적양을 제공하므로, 이 누적양의 변경 여부를 모니터링하여 해당 애플리케이션이 데이터를 송수신했는지 판단할 수 있다.

다른 변형 예에 따르면 트래픽 모니터부(826)는 통신 모듈로부터 송신되는 신호를 직접 획득하여 이를 이용해 특정 애플리케이션이 데이터를 송수신했는지 판단할 수 있다. 다만 송신되는 신호를 직접 이용할 경우 패킷을 분석하여 해당 패킷이 관련된 애플리케이션을 파악해 내야 하는데, 일반적으로 이는 복잡한 과정이므로, 패킷을 분석하는 과정을 단순화하는 기법이 필요할 수 있다.

트래픽 모니터부(826)는 데이터 송수신에 관한 정보를 항상 모니터할 필요는 없다. 트래픽 모니터부(826)는 예를 들어 알람이 등록된 경우 해당 알람 시각이 도래한 시점부터 미리 설정된 시간 동안만 모니터를 수행하면 된다. 그 이외의 시점에 발생하는 데이터 송수신은 반복 동기화 작업과 무관할 것으로 판단되기 때문이다.

변형 예에 따르면 트래픽 모니터부(826)는 데이터 송수신에 관한 정보를 항상 모니터하되, 알람이 등록된 경우 해당 알람 시각이 도래한 시점부터 미리 설정된 시간 동안에 데이터 송수신에 관한 정보가 감지되면, 이 경우에만 트래픽 분석부(824) 또는 동기화 스케줄러(822)에게 모니터링된 정보를 제공할 수도 있다.

다른 변형 예에 따르면, 트래픽 모니터부(826)는 데이터 송수신에 관한 정보를 항상 모니터하고, 알람 등록에 무관하게 항상 감지된 데이터 송수신에 관한 정보를 트래픽 분석부(824) 또는 동기화 스케줄러(822)에게 제공할 수도 있다. 이 경우 트래픽 분석부(824) 또는 동기화 스케줄러(822)는 등록된 알람 시각 정보를 이용해 동기화 작업을 감지할 수 있다.

트래픽 분석부(824)는 동기화 작업의 주기성을 검색/판단한다. 본 명세서는 전반적으로 주기적으로 수행되는 반복 동기화 작업에 대해 수행 시각의 조정을 가한다. 이를 위해 실제로 주기적으로 수행되는 반복 동기화 작업이 존재하는지 파악하여야 하며, 트래픽 분석부(824)는 이러한 기능을 수행한다.

트래픽 분석부(824)는 동기화 스케줄러(822)로부터 특정 애플리케이션에 의해 등록된 알람(타이머)에 관한 정보를 획득할 수 있다. 또한 트래픽 분석부(824)는 트래픽 모니터부(826)로부터 해당 애플리케이션에 의한 데이터 활동에 관한 정보, 예를 들어 TCP/UDP 세션 생성 및/또는 데이터 전송에 대한 정보를 획득할 수 있다. 트래픽 분석부(824)는 알람(타이머)에 관한 정보 및 데이터 활동에 관한 정보를 이용해 특정 알람에 의해 데이터가 송수신됐는지 판단한다. 예를 들어 알람 시각이 도래한 후 미리 설정된 시간 내에 데이터 송수신이 감지됐다면, 해당 알람에 의하여 데이터가 송수신된 것으로 판단할 수 있다.

동기화 스케줄러(822)는 도 3 내지 도 7을 참조하여 상술한 바와 같이 반복 동기화 작업의 수행 시점을 조정한다. 다만 어떠한 동기화 작업이 반복 동기화 작업에 해당하는지 판단하고 반복 동기화 작업의 주기를 파악하기 위해 트래픽 모니터부(826) 모니터 결과 및 트래픽 분석부(824)의 분석 결과를 활용한다. 예를 들어, 동기화 스케줄러(822) 알람 시각이 도래한 후 미리 설정된 시간 내에 데이터 송수신이 감지되는 경우만을 동기화 작업이 수행된 것으로 판단하고, 알람 시각이 도래한 후 미리 설정된 시간 내에 데이터 송수신이 감지되지 않는 경우 무시할 수 있다.

동기화 스케줄러(822)는 후술하는 과정에 따라 알람 관리자(930)의 알람의 트리거 시각을 조정하거나 앱위젯 관리자(940)의 새로고침 시각을 조정하거나 시간 라이브러리(950)의 트리거 시각을 조정할 수 있다. 단말의 위젯은 새로고침될 때 동기화가 필요할 수 있다. 그에 따라 앱위젯 관리자(940)의 새로고침 시각은 동기화 시점과 밀접한 관련이 있다.

도 10은 본 명세서의 제2 실시 예에 따르는 스크린 ON/OFF에 관한 상태 보고 과정의 순서도이다.

단계 1010에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 초기 설정을 송신한다. 초기 설정은 예를 들어 화이트리스트/블랙리스트에 관한 정보 및 주기 정보 중 적어도 일부를 포함할 수 있다. 화이트리스트는 주기성이 있는 것으로 간주되어 수행 시점 조정의 대상이 되는 애플리케이션(또는 반복 동기화 작업)의 목록이다. 블랙리스트는 주기성이 없는 것으로 간주되어 수행 시점이 조정되지 않도록 설정된 애플리케이션(또는 반복 동기화 작업)의 목록이다. 주기 정보는 주기적 수행으로 인정될 수 있는 최소 시간에 대한 정보를 포함할 수 있다. 예를 들어 1분 미만의 간격으로 반복적으로 수행되는 동작은 반복 동기화 작업으로 인정하지 않을 수 있다.

단계 1020에서 트래픽 분석부(824)는 트래픽 모니터부(826)에게 모니터링을 트리거하는 지시 메시지를 송신한다. 지시 메시지는 어떠한 이벤트를 모니터할 것인지에 대한 정보를 포함한다. 도 10의 실시 예에서는 스크린의 상태(on/off)를 모니터하도록 지시하는 정보가 포함된다.

단계 1030에서 트래픽 모니터부(826)는 알람 관리자(930) 및/또는 앱위젯 관리자(940)에게 브로드캐스트 등록 메시지를 송신한다. 브로드캐스트 등록 메시지는 스크린의 상태에 대한 정보를 브로드캐스트할 것을 요청하는 파라미터가 포함된다.

단계 1010 내지 단계 1030의 과정은 매 모니터링 동작마다 수행되는 것은 아니며, 최초 모니터링 설정 시, 또는 모니터링 설정을 변경할 필요가 있을 때 일회만 수행되면 충분하다. 모니터링 설정이 완료된 후에는 설정된 모니터링 설정에 따라 이후의 모니터링 동작이 2회 이상, 반복적으로 수행될 수 있다.

이후 단계 1040에서 알람 관리자(940)는 스크린 on/off 동작을 감지한다. 그에 따라 단계 1050에서 알람 관리자(940)는 감지된 스크린 on/off 동작을 브로드캐스트한다. 단계 1060에서 트래픽 모니터부(826)는 브로드캐스트를 통해 수신한 스크린 on/off 상태를 트래픽 분석부(824)에게 제공한다.

단계 1070에서 트래픽 분석부(824)는 스크린 on/off 상태에 관한 정보를 이용하여 동기화 작업의 주기성을 분석한다. 예를 들어 스크린이 켜진 상태에서 데이터가 송수신된 경우, 이는 사용자의 제어에 의한 데이터 송수신으로 보고, 해당 작업이 반복 동기화 작업이 아닌 것으로 파악할 수 있다. 반대로 스크린이 꺼진 상태에서 데이터가 송수신된 경우, 이는 동기화 작업에 의한 데이터 송수신으로 보고, 다른 정보를 더 고려하여 해당 작업이 반복 동기화 작업인지 여부를 파악할 수 있다.

단계 1080에서 트래픽 분석부(824)는 분석된 주기 정보를 동기화 스케줄러(822)에게 제공한다.

도 11은 본 명세서의 제2 실시 예에 따르는 소켓 활동 보고 과정의 순서도이다.

단계 1110에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 초기 설정을 송신한다. 초기 설정은 예를 들어 화이트리스트/블랙리스트에 관한 정보 및 주기 정보 중 적어도 일부를 포함할 수 있다. 화이트리스트는 주기성이 있는 것으로 간주되어 수행 시점 조정의 대상이 되는 애플리케이션(또는 반복 동기화 작업)의 목록이다. 블랙리스트는 주기성이 없는 것으로 간주되어 수행 시점이 조정되지 않도록 설정된 애플리케이션(또는 반복 동기화 작업)의 목록이다. 주기 정보는 주기적 수행으로 인정될 수 있는 최소 시간에 대한 정보를 포함할 수 있다. 예를 들어 1분 미만의 간격으로 반복적으로 수행되는 동작은 반복 동기화 작업으로 인정하지 않을 수 있다.

단계 1120에서 트래픽 분석부(824)는 트래픽 모니터부(826)에게 모니터링을 트리거하는 지시 메시지를 송신한다. 지시 메시지는 어떠한 이벤트를 모니터할 것인지에 대한 정보를 포함한다. 도 11의 실시 예에서는 소켓 활동을 모니터하도록 지시하는 정보가 포함된다.

단계 1130에서 트래픽 모니터부(826)는 TCP/IP 래퍼(1102)에게 소켓 활동 추적 등록 메시지를 송신한다. TCP/IP 래퍼(1102)는 애플리케이션의 통신 관련 시스템 콜(소켓 WRITE 등)을 담당하는 모듈의 예시이다. 소켓 활동 추적 등록 메시지는 TCP/IP 래퍼(1102)가 소켓 활동을 감지하면 이를 콜백해 줄 것을 요청하는 메시지이다. 소켓 활동은 소켓 OPEN, CONNECT, WRITE, READ, CLOSE 기타 소켓 통신을 위한 활동을 포함할 수 있다.

소켓 활동 추적 등록 메시지는 전체 소켓 활동 중 어떠한 활동을 감지하였을 때 감지된 활동을 통지할 것인지를 지시하는 파라미터를 포함할 수 있다. 예를 들어 트래픽 모니터부(826)는 CONNTECT 및 WRITE 활동만을 모니터하고자 한다면 소켓 활동 추적 등록 메시지에 CONNTECT 및 WRITE 활동에 대한 정보를 브로드캐스트할 것을 요청하는 파라미터를 포함시켜 송신할 수 있다.

단계 1110 내지 단계 1130의 과정은 매 모니터링 동작마다 수행되는 것은 아니며, 최초 모니터링 설정 시, 또는 모니터링 설정을 변경할 필요가 있을 때 일회만 수행되면 충분하다. 모니터링 설정이 완료된 후에는 설정된 모니터링 설정에 따라 이후의 모니터링 동작이 2회 이상, 반복적으로 수행될 수 있다.

이후 단계 1140에서 TCP/IP 래퍼(1102)는 통지의 대상인 소켓 활동을 감지한다. 그에 따라 단계 1150에서 TCP/IP 래퍼(1102)는 감지된 소켓 활동에 관한 정보를 트래픽 모니터부(826)에게 전달한다. 단계 1160에서 트래픽 모니터부(826)는 통지 받은 소켓 활동에 관한 정보를 처리/분석한다.

단계 1170에서 트래픽 모니터부(826)는 수신한 소켓 활동에 관한 정보를 트래픽 분석부(824)에게 제공한다.

단계 1180에서 트래픽 분석부(824)는 소켓 활동에 관한 정보를 이용하여 동기화 작업의 주기성을 분석한다. 예를 들어 알람 시각이 도래한 후 미리 설정된 시간 내에 소켓 WRITE(또는 CONNECT) 가 호출됐다면, 해당 알람에 의하여 데이터 송신이 개시된 것으로 파악할 수 있다.

단계 1190에서 트래픽 분석부(824)는 분석된 주기 정보를 동기화 스케줄러(822)에게 제공한다.

도 12은 본 명세서의 제2 실시 예에 따르는 데이터 활동 보고 과정의 순서도이다.

단계 1210에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 초기 설정을 송신한다. 초기 설정은 예를 들어 화이트리스트/블랙리스트에 관한 정보 및 주기 정보 중 적어도 일부를 포함할 수 있다. 화이트리스트는 주기성이 있는 것으로 간주되어 수행 시점 조정의 대상이 되는 애플리케이션(또는 반복 동기화 작업)의 목록이다. 블랙리스트는 주기성이 없는 것으로 간주되어 수행 시점이 조정되지 않도록 설정된 애플리케이션(또는 반복 동기화 작업)의 목록이다. 주기 정보는 주기적 수행으로 인정될 수 있는 최소 시간에 대한 정보를 포함할 수 있다. 예를 들어 1분 미만의 간격으로 반복적으로 수행되는 동작은 반복 동기화 작업으로 인정하지 않을 수 있다.

단계 1220에서 트래픽 분석부(824)는 트래픽 모니터부(826)에게 모니터링을 트리거하는 지시 메시지를 송신한다. 지시 메시지는 어떠한 이벤트를 모니터할 것인지에 대한 정보를 포함한다. 도 12의 실시 예에서는 데이터 활동을 모니터하도록 지시하는 정보가 포함된다.

단계 1230에서 트래픽 모니터부(826)는 와이파이 관리자(1202)에게 브로드캐스트 등록 메시지를 송신한다. 와이파이 관리자(1202)는 각 애플리케이션과 통신 하드웨어 모듈과의 중재자 역할을 하는 통신 중재자의 예시이다. 와이파이 관리자(1202) 대신 LTE 모듈의 관리자가 사용될 수도 있다. 실제로는 데이터 송수신을 위해 와이파이 모듈 및 LTE 모듈(기타 셀룰러 통신 모듈)이 병행적으로 사용되므로, 두 모듈 모두가 동시에 모니터링 대상이 될 수 있다.

단계 1230의 브로드캐스트 등록 메시지는 와이파이 관리자(1202)가 데이터 활동을 감지하면 이를 브로드캐스트해 줄 것을 요청하는 메시지이다. 데이터 활동은 와이파이 모듈이 데이터를 송수신하는 활동을 포함할 수 있다.

단계 1210 내지 단계 1230의 과정은 매 모니터링 동작마다 수행되는 것은 아니며, 최초 모니터링 설정 시, 또는 모니터링 설정을 변경할 필요가 있을 때 일회만 수행되면 충분하다. 모니터링 설정이 완료된 후에는 설정된 모니터링 설정에 따라 이후의 모니터링 동작이 2회 이상, 반복적으로 수행될 수 있다.

이후 단계 1240에서 와이파이 관리자(1202)는 통지의 대상인 데이터 활동을 감지한다. 그에 따라 단계 1250에서 와이파이 관리자(1202)는 감지된 데이터 활동에 관한 정보를 트래픽 모니터부(826)에게 전달한다. 단계 1260에서 트래픽 모니터부(826)는 통지 받은 데이터 활동에 관한 정보를 처리/분석한다.

단계 1270에서 트래픽 모니터부(826)는 수신한 데이터 활동에 관한 정보를 트래픽 분석부(824)에게 제공한다.

단계 1280에서 트래픽 분석부(824)는 데이터 활동에 관한 정보를 이용하여 동기화 작업의 주기성을 분석한다. 예를 들어 알람 시각이 도래한 후 미리 설정된 시간 내에 데이터 송신이 이루어졌다면, 해당 알람에 의하여 데이터 송신이 개시된 것으로 파악할 수 있다.

단계 1290에서 트래픽 분석부(824)는 분석된 주기 정보를 동기화 스케줄러(822)에게 제공한다.

도 13은 본 명세서의 제2 실시 예에 따르는 패키지 활동 보고 과정의 순서도이다.

단계 1310에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 초기 설정을 송신한다. 초기 설정은 예를 들어 화이트리스트/블랙리스트에 관한 정보 및 주기 정보 중 적어도 일부를 포함할 수 있다. 화이트리스트는 주기성이 있는 것으로 간주되어 수행 시점 조정의 대상이 되는 애플리케이션(또는 반복 동기화 작업)의 목록이다. 블랙리스트는 주기성이 없는 것으로 간주되어 수행 시점이 조정되지 않도록 설정된 애플리케이션(또는 반복 동기화 작업)의 목록이다. 주기 정보는 주기적 수행으로 인정될 수 있는 최소 시간에 대한 정보를 포함할 수 있다. 예를 들어 1분 미만의 간격으로 반복적으로 수행되는 동작은 반복 동기화 작업으로 인정하지 않을 수 있다.

단계 1320에서 트래픽 분석부(824)는 트래픽 모니터부(826)에게 모니터링을 트리거하는 지시 메시지를 송신한다. 지시 메시지는 어떠한 이벤트를 모니터할 것인지에 대한 정보를 포함한다. 도 13의 실시 예에서는 패키지 활동을 모니터하도록 지시하는 정보가 포함된다.

단계 1330에서 트래픽 모니터부(826)는 패키지 관리자(910)에게 브로드캐스트 등록 메시지를 송신한다.

단계 1330의 브로드캐스트 등록 메시지는 패키지 관리자(910)가 패키지 활동을 감지하면 이를 브로드캐스트해 줄 것을 요청하는 메시지이다. 패키지 활동은 패키지의 교환, 재시작, 변경 활동 중 적어도 일부를 포함할 수 있다. 브로드캐스트 등록 메시지는 구체적으로 어떠한 패키지 활동이 통지 대상인지를 지시하는 파라미터를 포함할 수 있다. 패키지 관리자(910)는 애플리케이션의 설치 등을 관리하는 구성부이다.

단계 1310 내지 단계 1330의 과정은 매 모니터링 동작마다 수행되는 것은 아니며, 최초 모니터링 설정 시, 또는 모니터링 설정을 변경할 필요가 있을 때 일회만 수행되면 충분하다. 모니터링 설정이 완료된 후에는 설정된 모니터링 설정에 따라 이후의 모니터링 동작이 2회 이상, 반복적으로 수행될 수 있다.

이후 단계 1340에서 패키지 관리자(910)는 통지의 대상인 패키지 활동을 감지한다. 그에 따라 단계 1350에서 패키지 관리자(910)는 감지된 패키지 활동에 관한 정보를 트래픽 모니터부(826)에게 전달한다. 단계 1360에서 트래픽 모니터부(826)는 통지 받은 패키지 활동에 관한 정보를 처리/분석한다.

단계 1370에서 트래픽 모니터부(826)는 수신한 패키지 활동에 관한 정보를 트래픽 분석부(824)에게 제공한다.

단계 1380에서 트래픽 분석부(824)는 수신한 패키지 활동에 따라 모니터링 설정을 지시하는 메시지를 트래픽 모니터부(826)에게 전달한다. 예를 들어 특정 애플리케이션이 교환/재시작/변경된 경우 이에 연관된 설정을 모두 초기화 하고 모니터링을 재개하도록 요청할 수 있다.

도 14는 본 명세서의 제2 실시 예에 따르는 단말의 OS 구성을 도시한다.

도 14에서는 트래픽 모니터부(826), 트래픽 분석부(824), 동기화 스케줄러(822)와 함께 데이터베이스(1410)가 도시된다. 데이터베이스는 주시리스트(1412), 무시리스트(1414) 및 화이트리스트(1416)를 포함한다. 데이터베이스(1410)은 저장 장소, 저장 모듈 또는 저장 구조의 일 실시 예로 제안된 것이며, 데이터베이스가 아닌 일반 파일이나 기타 방식으로 필요한 리스트들이 저장될 수 있다.

화이트리스트(1416)는 주기성이 확인된 애플리케이션(또는 반복 동기화 작업)을 지시하는 정보의 목록을 포함한다. 주시리스트(1412)는 주기성이 있는지 여부가 확정되지 않은 애플리케이션(또는 반복 동기화 작업)을 지시하는 정보의 목록을 포함한다. 무시리스트(1414)는 주기성이 없는 것으로 확정된 애플리케이션 (또는 동기화 작업)을 지시하는 정보의 목록을 포함한다. 각 리스트의 갱신/구성에 대해서는 도 15 내지 도 19를 참조하여 후술한다.

동기화 스케줄러(822)는 AlarmManager::SyncScheduler 및 AppWidgetManager::SyncScheduler를 포함할 수 있다. AlarmManager::SyncScheduler는 알람의 트리거 시점을 조정하는 동기화 스케줄러이다. AppWidgetManager::SyncScheduler는 위젯의 새로고침 시점을 조정하는 동기화 스케줄러이다.

도 15 및 도 16은 본 명세서의 제2 실시 예에 따르는 트리거 시각 조정 과정을 나타낸다. 도 15의 경우는 해당 동기화 작업이 주기성이 있는 것으로 이미 확인된 경우이고, 도 16의 경우는 해당 동기화 작업의 주기성 여부가 확인되지 않은 경우이다.

*도 15를 참조하면 단계 1510에서 Alarm::Set 모듈(1502) 및/또는 Widget::Resume 모듈이(1504) 스케줄링 함수(스케줄링 요청 또는 알람 등록 요청)를 호출한다. Alarm::Set 모듈(1502) 및/또는 Widget::Resume 모듈이(1504) 호출하는 스케줄링 함수는 알람 관리자 또는 위젯 관리자 등 알람 트리거/스케줄을 관리하는 모듈에 전달하기 위한 것이며, 동기화 스케줄러(822)는 중간에서 이들 스케줄링 함수의 호출을 감지/확인할 수 있다.

스케줄링 함수의 호출이 감지되면 단계 1520에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 해당 호출의 애플리케이션(또는 동기화 작업)의 주기 조회 메시지를 송신한다. 애플리케이션(동기화 작업)의 식별을 위해 애플리케이션 식별자 또는 동기화 작업 식별자가 활용될 수 있다. 실시 예에 따라서는 애플리케이션 식별자가 그대로 동기화 작업 식별자로 활용될 수 있다. 주기 조회 메시지가 수신되면 단계 1530에서 트래픽 분석부(824)는 해당 호출의 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있는지 판단한다. 도 15의 실시 예에서는 해당 호출의 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있는 것으로 가정한다. 이 경우 단계 1540에서 트래픽 분석부(824)는 해당 호출에 상응하는 반복 주기 정보를 동기화 스케줄러(822)에게 제공한다.

단계 1550에서 동기화 스케줄러(822)는 전달받은 반복 주기 정보에 기초하여 알람 트리거 시점(기타 스케줄링 시점)을 조정하여 알람 목록(1506)에 추가한다. 알람 트리거 시점의 조정 방식은 도 5를 참조하여 상술한 바와 같다.

도 16을 참조하면 단계 1610에서 Alarm::Set 모듈(1502) 및/또는 Widget::Resume 모듈이(1504) 스케줄링 함수(스케줄링 요청 또는 알람 등록 요청)를 호출한다. Alarm::Set 모듈(1502) 및/또는 Widget::Resume 모듈이(1504) 호출하는 스케줄링 함수는 알람 관리자 또는 위젯 관리자 등 알람 트리거/스케줄을 관리하는 모듈에 전달하기 위한 것이며, 동기화 스케줄러(822)는 중간에서 이들 스케줄링 함수의 호출을 감지/확인할 수 있다.

스케줄링 함수의 호출이 감지되면 단계 1620에서 동기화 스케줄러(822)는 트래픽 분석부(824)에게 해당 호출의 애플리케이션(또는 동기화 작업)의 주기 조회 메시지를 송신한다. 애플리케이션(동기화 작업)의 식별을 위해 애플리케이션 식별자 또는 동기화 작업 식별자가 활용될 수 있다. 주기 조회 메시지가 수신되면 단계 1630에서 트래픽 분석부(824)는 해당 호출의 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있는지 판단한다. 도 16의 실시 예에서는 해당 호출의 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있지 않은 것으로 가정한다. 이 경우 단계 1640에서 트래픽 분석부(824)는 해당 호출에 상응하는 반복 주기 정보가 없음을 알리는 지시자(지시 정보)를 동기화 스케줄러(822)에게 제공한다.

단계 1650에서 동기화 스케줄러(822)는 원래의 알람 트리거 시점(기타 스케줄링 시점)을 조정 없이 그대로 알람 목록(1506)에 추가한다.

도 17 및 도 19는 본 명세서의 제2 실시 예에 따르는 목록 관리 방식을 나타낸다.

도 18은 본 명세서의 제2 실시 예에 따르는 목록 관리 과정의 순서도이다.

도 17 내지 도 19는 기본적으로 동일하거나 유사한 방식을 여러 관점에서 설명한 것이다.

도 17을 참조하면, 단계 1710에서 동기화 스케줄러(822)가 특정 스케줄링 요청에 대한 주기 정보를 요청한다. 단계 1720에서 트래픽 분석부(824)는 해당 스케줄링 요청에 상응하는 애플리케이션(또는 반복 동기화 작업)이 화이트리스트(1416)에 존재하는지 체크한다. 화이트리스트(1416)는 애플리케이션(또는 반복 동기화 작업)과 그에 상응하는 주기 정보도 화이트리스트(1416)에 연관시켜 저장한다.

단계 1730에서 트래픽 분석부(824)는 해당 스케줄링 요청에 상응하는 애플리케이션(또는 반복 동기화 작업)이 화이트리스트(1416)에 존재하면 해당 애플리케이션(또는 반복 동기화 작업)에 상응하는 주기 정보를 동기화 스케줄러(822)에게 제공한다. 반대로 스케줄링 요청에 상응하는 애플리케이션(또는 반복 동기화 작업)이 화이트리스트(1416)에 존재하지 않으면 트래픽 분석부(824)는 주기 정보가 발견되지 않았음을 지시하는 지시자를 동기화 스케줄러(822)에게 전달한다.

단계 1740에서 트래픽 분석부(824)는 스케줄링 요청에 상응하는 애플리케이션(또는 반복 동기화 작업)이 화이트리스트(1416)에 존재하지 않으면, 해당 스케줄링 요청에 상응하는 애플리케이션(또는 동기화 작업)의 식별자와 그 실행 시점에 관한 정보를 주시리스트(1412)에 저장한다. 주시리스트에 저장된 정보를 토대로 추후 주기성 여부의 판단이 수행될 수 있다.

단계 1750에서 트래픽 분석부(824)는 2회 이상의 스케줄링 요청에 상응하는 애플리케이션(또는 동기화 작업)의 주기성을 확인하여 주기성이 없다고 판단되면 해당 애플리케이션(또는 동기화 작업)을 무시리스트(1414)에 추가한다.

도 18을 참조하면, 단계 1810에서 트래픽 분석부(824)는 동기화 스케줄러(822)로부터 특정 애플리케이션(또는 동기화 작업)에 대한 주기 정보를 요청하는 요청 메시지를 수신한다. 단계 1820에서 트래픽 분석부(824)는 해당 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있는지 판단한다. 해당 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있으면 과정은 단계 1825로 진행하여 트래픽 분석부(824)는 동기화 스케줄러(822)에게 해당 애플리케이션(또는 동기화 작업)에 상응하는 주기 정보를 제공한다.

해당 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 포함돼 있지 않으면 과정은 단계 1830으로 진행한다.

단계 1830에서 트래픽 분석부(824)는 해당 애플리케이션(또는 동기화 작업)에 관한 주기 정보가 검색되지 않았음을 알리는 응답을 동기화 스케줄러(822)에게 제공한다. 또한 트래픽 분석부(824)는 해당 애플리케이션(또는 동기화 작업)의 식별자 및 그에 관한 알람 수행 시점을 주시리스트(1412)에 추가한다.

단계 1840에서 트래픽 분석부(824)는 추후 동일한 애플리케이션(또는 동기화 작업)에 관한 스케줄링 요청이 2회 더 있을 때(총 3회의 스케줄링 요청이 있을 때) 해당 스케줄링 요청의 주기성을 검색한다. 예를 들어 3회의 스케줄링 요청 시작 시점 중 1회-2회 시작 시점 사이의 간격과 2회-3회 시작 시점 사이의 간격이 미리 설정된 한계값 이내인 경우 주기성이 있는 것으로 판단한다. 이 경우 해당 반복 동기화 작업의 주기는 1회-2회 시작 시점 사이의 간격과 2회-3회 시작 시점 사이의 간격의 평균값이 될 수 있다. 미리 설정된 한계값은 절대값으로 정해진 값이 될 수도 있고, 1회-2회 시작 시점 사이의 간격 및/또는 2회-3회 시작 시점 사이의 간격에 따라 비례하여, 또는 기타 연관 관계를 가지고 변하는 값이 될 수도 있다.

단계 1850에서 트래픽 분석부(824)는 해당 스케줄링 요청의 주기성 여부를 판단한다. 주기성이 추정되는 경우 과정은 단계 1860으로 진행한다. 단계 1860에서 트래픽 분석부(824)는 주기성이 추정되는 애플리케이션(또는 반복 동기화 작업)의 식별자 및 그 주기 정보를 연관시켜서 화이트리스트(1416)에 저장한다. 주기성이 없는 것으로 추정되는 경우 과정은 단계 1870으로 진행한다. 단계 1870에서 트래픽 분석부(824)는 주기성이 없는 것으로 추정되는 애플리케이션(또는 반복 동기화 작업)의 식별자를 무시리스트(1414)에 추가한다.

화이트리스트(1416)에 포함되는 애플리케이션(또는 반복 동기화 작업)에 대해 화이트리스트(1416)에 기록된 주기 정보와 비교하여 오차범위를 벗어나는 스케줄링 요청이 있는 경우 해당 애플리케이션(또는 반복 동기화 작업)을 화이트리스트(1416)로부터 제거하고 다시 주기성을 판단할 수 있다. 또한 애플리케이션이 새로 설치되거나 버전이 변경된 경우 해당 애플리케이션(또는 반복 동기화 작업)을 화이트리스트(1416)로부터 제거하고 다시 주기성을 판단할 수 있다. 다른 실시 예에 따르면 단말의 전원이 꺼졌다가 다시 켜지면 동적으로 도 18과 같은 과정을 통해 화이트리스트(1416)에 추가된 애플리케이션(또는 반복 동기화 작업)을 화이트리스트(1416)로부터 제거하고 다시 주기성을 판단할 수 있다.

애플리케이션의 버전 변경, 갱신 등의 동작이 있으면 해당 애플리케이션에 연관된 항목은 모든 리스트(화이트리스트(1416), 주시리스트(1412), 무시리스트(1414))로부터 제거된다. 이후 새로운 알람 요청(스케줄링 요청)이 있을 때 다시 주기성 판단이 수행될 수 있다.

도 19를 참조하면 단계 1910에서 트래픽 모니터부(826)는 소켓 API 동작, 스크린 ON/OFF 상태 변경, 송수신 동작 등에 관한 정보에 따라 그 상태 정보를 알리는 상태 변경 보고를 트래픽 분석부(824)에게 제공한다. 상태 변경 보고를 수신한 트래픽 분석부(824)는 단계 1920에서 해당 상태 변경에 연관된 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 존재하는지 판단한다. 해당 상태 변경에 연관된 항목이 화이트리스트(1416)에 존재하는 경우 화이트리스트(1416)에 포함된 해당 항목의 주기 정보가 활용될 수 있다.

단계 1930에서 트래픽 분석부(824)는 해당 상태 변경에 연관된 애플리케이션(또는 동기화 작업)이 화이트리스트(1416)에 존재하지 않는 경우 주시리스트(1412)에 저장된 항목들을 이용하여(1930) 해당 애플리케이션(또는 동기화 작업)의 주기성을 판단한다(1940). 주기성 판단 결과 주기성이 인정되면 해당 애플리케이션(또는 동기화 작업)에 관한 항목이 화이트리스트(1416)에 추가된다. 반대의 경우 해당 애플리케이션(또는 동기화 작업)에 관한 항목이 무시리스트(1414)에 추가된다.

도 20은 본 발명에 따른 애플리케이션 동기화 관리 방법의 일실시예의 수행과정을 도시한 도면이다.

도 20을 참조하면, 제어부(220)는 알람 트리거(Trigger) 신호가 발생하였는지 여부를 확인한다(S2000).

알람 트리거 신호가 발생된 경우에는, 제어부(220)는 상기 알람 트리거 신호에 의해 트리거된 알람이 애플리케이션 동기 관리 대상 알람인지 여부를 확인한다(S2010). 여기서, 일부 실시예로 상기 애플리케이션 동기 관리 대상 알람은 화이트리스트(1416)에 포함된 반복 동기화 작업과 연관된 알람일 수 있다. 제어부(220)는 알람 트리거 신호에 의해 트리거된 알람과 연관된 반복 동기화 작업이 화이트리스트(1416)에 포함된 경우에, 상기 알람을 애플리케이션 동기 관리 대상 알람으로 확인한다.

일부 실시예로 상기 애플리케이션 동기 관리 대상 알람은 주시리스트(1412)에 포함된 반복 동기화 작업과 연관된 알람일 수 있다. 제어부(220)는 알람 트리거 신호에 의해 트리거된 알람과 연관된 반복 동기화 작업이 주시리스트(1412)에 포함된 경우에, 상기 알람을 애플리케이션 동기 관리 대상 알람으로 확인한다.

일부 실시예로, 상기 애플리케이션 동기 관리 대상 알람은 화이트리스트(1416) 및 주시리스트(1412) 중 적어도 하나에 포함된 반복 동기화 작업과 연관된 알람일 수 있다. 제어부(220)는 알람 트리거 신호에 의해 트리거된 알람이 화이트리스트(1416) 및 주시리스트(1412) 중 적어도 하나에 포함된 반복 동기화 작업과 연관된 알람인 경우에, 상기 알람을 애플리케이션 동기 관리 대상 알람으로 확인한다.

상기 알람이 애플리케이션 동기 관리 대상 알람인 경우에는, 제어부(220)는 상기 알람이 사용자 인터페이스(UI : User Interface) 알람인지 여부를 확인한다(S2020). 여기서 UI 알람은 UI 동작을 포함하는 알람을 의미하며, UI 동작 알람을 포함한다. UI 동작 알람은 발생시에 상위상태(foreground)로 올라와야 하며, 화면이 켜져야 한다.

상기 알람이 UI 알람인 경우에는, 제어부(220)는 상기 알람과 연관된 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 추가한다(S2040). 상기 알람이 UI 알람인 경우에는, 제어부(220)는 상기 알람과 연관된 반복 동기화 작업에 대해서는 애플리케이션 동기화 관리를 수행한지 않는다. 상기 반복 동기화 작업에 대한 알람은 시간 조절 없이 애플리케이션이 요청한 시간에 따라 등록된다.

상기 알람이 UI 알람이 아닌 경우에는, 제어부(220)는 상기 알람이 이상 동작 알람인지 여부를 확인한다(S2030).

상기 알람이 이상 동작 알람인 경우에는, 제어부(220)는 상기 알람과 연관된 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 추가한다(S2040).

일부 실시예로, 상기 알람이 애플리케이션 동기 관리 대상 알람인 경우에는, 단계 S2030이 수행되고, 상기 알람이 이상 동작 알람인 경우에는, 단계 S2040,이 수행되며, 상기 알람이 이상 동작 알람이 아닌 경우에는, 단계 S2020이 수행될 수 있다. 그리고, 상기 알람이 UI 알람인 경우에는, 단계 S2040이 수행될 수 있다.

일부 실시예로, 도 20의 단계 S2000 내지 S2040,에서 단계 S2020가 삭제되어 실시될 수 있다.

일부 실시예로, 도 20의 단계 S2000 ,내지 S2040에서 단계 S2030이 삭제되어 실시될 수 있다.

도 21은 본 발명에 따른 알람 판별 방법의 일실시예의 수행과정을 도시한 도면이다.

도 21을 참조하면, 도 20의 단계 S2020은 도 21의 S2100 내지 S2140,을 포함할 수 있다.

제어부(220)는 상위상태(foreground) 신호가 발생하였는지 여부를 확인한다(S2100).

Foreground 신호가 발생한 경우에는, 제어부(220)는 판별 대상 알람과 상위상태로 된 알람의 아이디(ID)가 일치하고, 소정의 시간 간격(이하에서, 톨러런스(Tolerance 시간이라고 명명함) 내에 foreground 신호가 발생하였는지 여부를 확인한다(S2110). 상기 Tolerance 시간은 사전에 설정될 수 있고, 알람 트리거 신호 후 foreground 신호의 발생 내역을 기초로 업데이트될 수 있다. 일예, 상기 Tolerance 시간은 10초로 설정될 수 있다.

아이디가 일치하고, Tolerance 시간 내에 foreground 신호가 발생한 경우에는, 제어부(220)는 스크린이 온(On) 이면서 Tolerance 시간 내에 온 되었는지 여부를 확인한다(S2120).

스크린이 Tolerance 시간 내에 온 된 경우에는, 제어부(220)는 상기 판별 대상 알람과 연관된 반복 동기화 작업의 foreground 횟수가 사전에 설정된 횟수를 만족하는지 여부를 확인한다(S2130).

일부 실시예로, 상기 사전에 설정된 횟수는 2회일 수 있다. UI 동작 알람은 단일 알람일 경우와 다중 알람일 경우가 있다. 알람이 UI 동작일 조건은 알람이 동작할 때 마다 UI 제어를 해야 하는 것이다. 이를 기록하며, 2회 이상 발생시에 무시리스트(1414)로 이동하게 된다.

다중 알람의 경우에는 2가지로 나뉘게 된다. 하나의 애플리케이션에서 발생한 각 알람의 주기가 같은 경우와 다른 경우이다. 각 알람의 주기가 같은 경우와 혹은 그 주기가 UI 알람의 공배수인 경우에는, 매 알람이 울릴 때 마다 항상 UI 변동이 있고 어느 알람이 UI 알람인지 알 수 없게 되므로 모든 해당 알람들이 무시리스트(1414)로 이동한다.

주기가 서로 모두 다른 경우에는, 각 알람들의 특성 파악이 가능하다. 따라서 여러 알람 중 UI 동작 알람은 2회 이상 발생할 경우 무시리스트(1414)로 이동하고 나머지 일반 알람의 경우에는 애플리케이션 동기의 규칙에 따라 무시리스트(1414)나 화이트리스트(1416)로 이동한다.

상기 foreground 횟수가 사전에 설정된 횟수를 만족하는 경우에는, 제어부(220)는 상기 판별 대상 알람을 UI 동작 알람으로 확인한다(S2140). 제어부(220)는 상기 알람과 연관된 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 포함할 수 있다.

도 22 및 23은 본 발명에 따른 이상 동작 판별 방법의 일실시예의 수행과정을 도시한 도면이다.

도 22 및 23을 참조하면, 제어부(220)는 이상 동작 판별 대상 알람과 연관된 반복 동기화 작업이 기존 주기 타입에 맞는지 여부를 확인한다(S2200). 여기서 주기 타입은 반복 동기화 작업과 연관된 알람 발생에 따른 애플리케이션의 데이터 송수신 관련 동작(트래픽)의 발생 주기를 의미한다. 일예로, 반복 동기화 작업의 주기 타입은 다음과 같다.

1: H-H-H-H

2: M-H-M-H

3: M-M-H-M-M-H

여기서, H(Hit)는 알람 발생 후 해당 애플리케이션에서 트랙픽이 발생한 경우를 의미하고, M(Miss)는 알람 발생 후 해당 애플리케이션에서 트래픽 발생이 없는 경우를 의미한다.

또한, 다음와 같이 일부 주기 타입을 예외처리한다.

-M-H-H -> H-H

- H-M->M

상기 반복 동기화 작업이 기존 주기 타입에 맞지 않는 경우에는, 제어부(220)는 상기 반복 동기화 작업의 히트카운트가 N회 이하인지 여부를 확인한다(S2300). 여기서, N회는 화이트리스트(1416)로 애플리케이션이 배정된 이후에 주기가 동기화 되어 변하기 바로 전의 카운트이다. 히트카운트(Hitconut)가 4회 일 때 알람 트리거 시각이 변화는 실시예에서는 N은 3회가 된다.

상기 트래픽 발생이 N회 이하가 아닌 경우에는, 제어부(220)는 화이트리스트에서 상기 반복 동기화 작업을 지시하는 정보를 제거하고 미스 카운트(miss count)를 증가시킨다(S2310). 일부 실시예로 제어부(220)는 미스 카운트를 증가 시키는 대신에 상기 반복 동기화 작업의 히트카운트를 감소시킬 수 있다.

상기 트래픽 발생이 N회 이하인 경우에는, 제어부(220)는 다음 알람이 등록되어 있는지 여부를 확인한다(S2320).

다음 알람이 등록된 경우에는, 제어부(220)는 상기 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 추가한다(S2340). 상기 반복 동기화 작업과 연관된 알람에 대한 네트워크 트래픽이 발생하지 않은 뒤 다음 알람이 등록되어 있을 경우에는, 제어부(220)는 특별한 제어를 하기 않고 상기 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 추가하고 기존 알람 시간을 유지하도록 제어한다. 제어부(220)는 알람이 등록되어 있는 목록에서 현재 변경한 애플리케이션의 알람 정보를 비교하여 다음 알람이 등록되어 있는지 여부를 확인한다.

다음 알람이 등록되지 않은 경우에는, 제어부(220)는 롤백(Roll Back)을 수행한다(S2330). 여기서, 제어부(220)는 다음 알람이 등록되지 않은 경우에 복구 함수가 실행되도록 제어할 수 있다. 상기 복구 함수는 이상동작이 발생한 알람의 정보를 확인하고, 상기 정보를 바탕으로 원래 지정된 알람 시간으로 다음 알람을 등록하여 애플리케이션이 정상 작동하도록 한다. 그리고, 제어부(220)는 상기 반복 동기화 작업을 지시하는 정보를 무시리스트(1414)에 추가한다(S2340).

도 20의 단계 S2030은 도 22 및 23의 단계 S2200 내지 단계 S2330을 포함할 수 있다. 단계 S2030 수행 시 단계 S2200은, 이상 동작 판별 대상 알람(단계 S2030에서 이상 동작 알람 확인 대상)과 연관된 반복 동기화 작업이 화이트리스트(1416)에 포함되어 있을 때, 수행될 수 있다.

도 24은 본 발명에 따른 이상 동작 판별 방법의 다른 실시예의 수행과정을 도시한 도면이다.

도 24를 참조하면, 제어부(220)는 이상 동작 판별 대상 알람과 연관된 반복 동기화 작업이 일정한 규칙성을 가져서 주기 타입이 화이트리스트 조건에 맞는지 여부를 확인한다(S2400).

화이트리스트 조건에 맞는 경우에는, 제어부(220)는 상기 반복 동기화 작업을 지시하는 정보를 화이트리스트(1416)에 추가한다(S2410). 그리고, 제어부(220)는 상기 알람이 이상 동작이 아님을 확인할 수 있다. 화이트리스트 조건은 도 18에 전술된 조건일 수 있다.

화이트리스트 조건에 맞지 않는 경우에는, 제어부(220)는 재검사를 수행한다.

도 20의 단계 S2030은 도 24의 단계 S2400 및 S2410을 포함할 수 있다. 단계 S2030 수행 시 단계 S2400은, 이상 동작 판별 대상 알람(단계 S2030에서 이상 동작 알람 확인 대상)과 연관된 반복 동기화 작업이 주시리스트(1412)에 포함되어 있을 때, 수행될 수 있다.

이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.

또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.

이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.

본 명세서의 일 실시 예에 따른 단말은 휴대폰, PDA(Personal Digital Assistant), 내비게이션(navigation), 디지털 방송 수신기, PMP(Portable Multimedia Player) 등과 같은 휴대용 전자기기 장치 중 일부를 포함할 수 있다.

본 명세서가 속하는 기술분야의 통상의 지식을 가진 자는 본 명세서가 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시 예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 명세서의 범위는 상기 상세한 설명보다는 후술하는 특허청구의 범위에 의하여 나타내어지며, 특허청구의 범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 명세서의 범위에 포함되는 것으로 해석되어야 한다.

한편, 본 명세서와 도면에는 본 명세서의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 명세서의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 명세서의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 명세서의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 명세서가 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

Claims (34)

1. 단말의 애플리케이션 동기화 방법에 있어서,
   애플리케이션을 위한 제1 알람 등록 요청을 수신하는 단계;
   상기 제1 알람 등록 요청에 상응하는 제1 알람이 트리거되었는지 판단하는 단계;
   상기 제1 알람 등록 요청에 상응하는 상기 제1 알람이 트리거된 경우, 상기 제1 알람이 트리거된 이후 미리 설정된 시간 간격 이내에 상기 애플리케이션과 관련된 데이터가 송수신되는지 판단하는 단계; 및
   상기 데이터가 상기 제1 알람이 트리거된 이후 상기 미리 설정된 시간 간격 이내에 송수신된 경우, 상기 애플리케이션의 주기를 추정하는 단계를 포함하고,
   동기화 작업의 수행 시점은 상기 제1 알람 등록 요청과 관련된 동기화 작업 식별자가 제1 리스트에 포함되어 있는지 여부에 따라 결정되고,
   상기 데이터가 상기 제1 알람이 트리거된 이후 상기 미리 설정된 시간 간격 이내에 송수신되지 않은 경우, 상기 동기화 작업 식별자는 제2 리스트에 추가되는 것을 특징으로 하는 동기화 방법.
2. 제1항에 있어서, 상기 방법은,
   상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있는지 판단하는 단계; 및
   상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있는 경우, 상기 동기화 작업 식별자에 연관된 주기 정보에 따라 상기 제1 알람 등록 요청에 상응하는 반복 동기화 작업의 수행 시점을 조정하는 단계를 더 포함하는 동기화 방법.
3. 제2항에 있어서, 상기 방법은,
   상기 제1 알람 등록 요청과 관련된 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있지 않은 경우, 상기 제1 알람 등록 요청에 상응하는 제2 알람 등록 요청 및 제3 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신되었는지 판단하는 단계;
   상기 제1 알람 등록 요청에 상응하는 상기 제2 알람 등록 요청 및 상기 제3 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신된 경우, 상기 제1 알람 등록 요청, 상기 제2 알람 등록 요청 및 상기 제3 알람 등록 요청의 트리거 시점들 간의 간격을 기초로 상기 제1 알람 등록 요청의 주기성(periodicity)을 판단하는 단계;
   상기 제1 알람 등록 요청이 주기성을 갖는 것으로 판단되는 경우, 상기 트리거 시점들 간의 간격을 기초로 주기 정보를 생성하는 단계; 및
   상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자 및 상기 주기 정보를 상기 제1 리스트에 추가하는 단계를 더 포함하는 동기화 방법.
4. 제3항에 있어서, 상기 방법은,
   상기 제1 알람 등록 요청이 상기 주기성을 갖지 않는 것으로 판단되는 경우, 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 제2 리스트에 추가하는 단계를 더 포함하는 동기화 방법.
5. 제4항에 있어서, 상기 방법은,
   상기 제1 알람 등록 요청에 상응하는 둘 이상이 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신되지 않은 경우, 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 상기 제1 알람 등록 요청의 트리거 시점과 연관시켜 제3 리스트에 추가하는 단계를 더 포함하는 동기화 방법.
6. 제5항에 있어서, 상기 방법은,
   상기 애플리케이션이 업데이트되는 경우, 상기 제1 리스트, 상기 제2 리스트 및 상기 제3 리스트로부터 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 삭제하는 단계를 더 포함하는 동기화 방법.
7. 제1항에 있어서,
   상기 제1 알람 등록 요청과 관련된 동기화 작업 식별자가 상기 제2 리스트에 포함되어 있는 경우, 상기 제1 알람 등록 요청에 상응하는 반복 동기화 작업의 수행 시점을 조정하지 않는 것을 특징으로 하는 동기화 방법.
8. 애플리케이션의 동기화를 수행하는 단말에 있어서,
   데이터를 송수신하도록 설정된 송수신부; 및
   상기 송수신부와 연결된 제어부를 포함하고,
   상기 제어부는,
   애플리케이션을 위한 제1 알람 등록 요청을 수신하고,
   상기 제1 알람 등록 요청에 상응하는 제1 알람이 트리거되었는지 판단하고,
   상기 제1 알람 등록 요청에 상응하는 상기 제1 알람이 트리거된 경우, 상기 제1 알람이 트리거된 이후 미리 설정된 시간 간격 이내에 상기 애플리케이션과 관련된 데이터가 송수신되는지 판단하고,
   상기 데이터가 상기 제1 알람이 트리거된 이후 상기 미리 설정된 시간 간격 이내에 송수신된 경우, 상기 애플리케이션의 주기를 추정하도록 설정되고,
   동기화 작업의 수행 시점은 상기 제1 알람 등록 요청과 관련된 동기화 작업 식별자가 제1 리스트에 포함되어 있는지 여부에 따라 결정되고,
   상기 데이터가 상기 제1 알람이 트리거된 이후 상기 미리 설정된 시간 간격 이내에 송수신되지 않은 경우, 상기 동기화 작업 식별자는 제2 리스트에 추가되는 것을 특징으로 하는 단말.
9. 제8항에 있어서,
   상기 제어부는,
   상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있는지 판단하고,
   상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있는 경우, 상기 동기화 작업 식별자에 연관된 주기 정보에 따라 상기 제1 알람 등록 요청에 상응하는 반복 동기화 작업의 수행 시점을 조정하도록 설정되는 것을 특징으로 하는 단말.
10. 제9항에 있어서,
    상기 제어부는,
    상기 제1 알람 등록 요청과 관련된 동기화 작업 식별자가 상기 제1 리스트에 포함되어 있지 않은 경우, 상기 제1 알람 등록 요청에 상응하는 제2 알람 등록 요청 및 제3 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신되었는지 판단하고,
    상기 제1 알람 등록 요청에 상응하는 상기 제2 알람 등록 요청 및 상기 제3 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신된 경우, 상기 제1 알람 등록 요청, 상기 제2 알람 등록 요청 및 상기 제3 알람 등록 요청의 트리거 시점들 간의 간격을 기초로 상기 제1 알람 등록 요청의 주기성(periodicity)을 판단하고,
    상기 제1 알람 등록 요청이 주기성을 갖는 것으로 판단되는 경우, 상기 트리거 시점들 간의 간격을 기초로 주기 정보를 생성하고,
    상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자 및 상기 주기 정보를 상기 제1 리스트에 추가하도록 설정되는 것을 특징으로 하는 단말.
11. 제10항에 있어서,
    상기 제어부는,
    상기 제1 알람 등록 요청이 상기 주기성을 갖지 않는 것으로 판단되는 경우, 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 제2 리스트에 추가하도록 설정되는 것을 특징으로 하는 단말.
12. 제11항에 있어서,
    상기 제어부는,
    상기 제1 알람 등록 요청에 상응하는 둘 이상이 알람 등록 요청이 상기 제1 알람 등록 요청이 수신되기 이전에 수신되지 않은 경우, 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 상기 제1 알람 등록 요청의 트리거 시점과 연관시켜 제3 리스트에 추가하도록 설정되는 것을 특징으로 하는 단말.
13. 제12항에 있어서,
    상기 제어부는,
    상기 애플리케이션이 업데이트되는 경우, 상기 제1 리스트, 상기 제2 리스트 및 상기 제3 리스트로부터 상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자를 삭제하도록 설정되는 것을 특징으로 하는 단말.
14. 제8항에 있어서,
    상기 제어부는,
    상기 제1 알람 등록 요청과 관련된 상기 동기화 작업 식별자가 상기 제2 리스트에 포함되어 있는 경우, 상기 제1 알람 등록 요청에 상응하는 반복 동기화 작업의 수행 시점을 조정하지 않도록 설정되는 것을 특징으로 하는 단말.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제

Images