KR102093173B1 - 상이한 타입의 통신에 최적화된 복수의 서버를 이용한 디바이스 모니터링 - Google Patents

Abstract

전자 디바이스 모니터링 시스템은 전자 디바이스와 통신하기 위해 2가지의 상이한 타입의 서버를 이용한다. 신속 접촉 서버이어도 되는 한 가지 타입의 서버는 전자 디바이스와의 상대적으로 짧고 빈번한 통신에 최적화되거나 이를 위해 구성된다. 다른 하나의 타입의 서버는 전자 디바이스와의 덜 빈번하지만 (통상적으로) 더 긴 통신에 최적화되거나 이를 위해 구성된다. 몇몇 실시예에서, 전자 디바이스는 신속 접촉 서버와 비교적 빈번하게(예컨대, 수 분마다) 통신하도록 구성된다. 전자 디바이스가 분실되거나 도난당한 것으로서 보고되는 때에, 신속 접촉 서버는 전자 디바이스에게 보안 관련 지시를 획득하기 위해 다른 하나의 타입의 서버에 접촉하도록 지시할 수 있다.

Description

상이한 타입의 통신에 최적화된 복수의 서버를 이용한 디바이스 모니터링{DEVICE MONITORING USING MULTIPLE SERVERS OPTIMIZED FOR DIFFERENT TYPES OF COMMUNICATIONS}

본 발명은 전반적으로 전자 디바이스를 분실 또는 도난으로부터 보호하는 것에 관한 것으로, 보다 구체적으로는 이러한 디바이스를 모니터링하고 이들은 빈번하게 그리고 충분한 예고없이(on short notice) 접촉할 수 있도록 하는 시스템 및 방법에 관한 것이다.

개인용 전자 컴퓨팅 또는 통신 디바이스는 분실 또는 도난되는 경우가 많다. 이러한 디바이스 상에는 일상적으로 사적인 정보(proprietary information)가 저장되므로, 이러한 사적인 정보 또는 민감한 데이터를 보호하고 이러한 디바이스를 되찾기 위한 필요성은 자명하다.

랩탑 및 크게는 셀룰러 전화, PDA, 스마트폰(예컨대, Blackberry™, iPhone™), 메모리 스틱, 개인 미디어 디바이스(예컨대, iPod™), 게이밍 디바이스, 태블릿 컴퓨터, 전자책 및 개인용 컴퓨터와 같은 기타 전자 디바이스는 이들이 도난의 경우에 되찾을 수 있도록 원격으로 추적되는 경우가 많다. 이러한 추적은 위치 정보를 원격 저장 사이트(remote storage site), 이메일 서버, 또는 개인용 모바일 전자 디바이스에 전송함으로써 시행될 수 있다.

추적된 디바이스와의 통신 동안, 데이터 삭제, 암호화, 암호화 키 삭제, 소프트웨어를 업데이트(updating software), 데이터를 검색(retrieving data), 스크린샷을 검색(retrieving screen shot), 카메라샷을 검색(retrieving camera shot) 등을 위한 명령이 전송될 수 있다.

추적은 종래에는 과도한 대역폭 사용을 방지하고 절도범이 알아챌 위험을 최소화하기 위해 단속적으로 발생한다. 2개의 이러한 추적 통신 사이에 디바이스가 도난되는 때에는, 디바이스의 소유주 또는 사용자는 디바이스 상의, 데이터 삭제와 같은, 보안 액션(security action)을 트리거하기 위해서는 그 다음 추적 통신까지 기다려야만 한다.

전자 디바이스 모니터링 시스템은 사용자의 전자 디바이스와 통신하기 위해 2개의 상이한 타입의 서버를 이용한다. 신속 접촉 서버(rapid contact server)이어도 되는 한 가지 타입의 서버는 전자 디바이스와의 비교적 짧고 빈번한 통신에 최적화되거나 구성된다. 다른 하나의 타입의 서버는 전자 디바이스와의 덜 빈번하지만 (통상적으로) 더 긴 통신에 최적화되거나 구성된다. 몇몇 실시예에서, 전자 디바이스는 신속 접촉 서버와 비교적 빈번하게(예컨대, 수 분마다) 통신하도록 구성된다. 전자 디바이스가 분실되거나 도난된 것으로서 보고되는 때에, 신속 접촉 서버는 보안 관련 명령을 획득하기 위해 다른 타입의 서버를 접촉하도록 전자 디바이스에게 지시할 수 있다. 2개의 서버를 상이하게 최적화함으로써, 전자 디바이스는 각각 상이한 프로토콜에 따라 통신하도록 구성된다고 할 수 있으며, 여기서 각각의 프로토콜은 특정 서버에 대해 최적화된다.

본 과제 해결 수단 부분은 본 명세서에 설명되고 청구되는 발명의 대상의 범위를 기술하기 위한 의도의 포괄적 개요는 아니다. 본 과제 해결 수단 부분은, 아래에 설명되는 상세한 설명에 대한 서문으로서, 발명의 대상의 기본적인 이해를 제공하기 위해 발명의 대상의 양태를 간략화된 형태로 제공한다. 본 과제 해결 수단 부분, 도면 또는 이하의 상세한 설명의 어떠한 것도 본 발명의 규정하거나 한정하도록 주장하지 않으며, 본 발명은 청구항들에 의해서만 정해진다.

개시된 발명의 대상의 특성 및 장점뿐만 아니라 발명의 대상의 바람직한 사용 모드에 대한 더 완전한 이해를 위해, 첨부 도면과 함께 정독할 시에 이하의 상세한 설명에 대한 참조가 이루어져야 한다. 도면에서는 동일한 도면 부호가 동일하거나 유사한 단계 또는 부분을 나타낸다.
도 1은 개시된 발명의 대상의 실시예에 따른 신속 접촉 시스템의 기본 블록도이다.
도 2는 디바이스에 의해 신속 접촉 시스템에 전송되는 신속 접촉 패킷의 개략도이다.
도 3은 디바이스와 메인 서간 간에 송신되는 정규 패킷(regular packet)의 개략도이다.
도 4는 개시된 발명의 대상의 실시예에 따른 신속 접촉 시스템에서 디바이스에 의해 수행되는 프로세스의 흐름도이다.
도 5는 신속 접촉 시스템에 의해 수행되는 프로세스의 흐름도이다.
도 6은 인증 토큰(authentication token)을 신속 접촉 시스템으로부터 디바이스에 송신하기 위한 흐름도이다.
도 7은 디바이스 상의 신속 발신(rapid calling)을 가능하게 하는 시퀀스 다이아그램이다.
도 8은 디바이스를 위한 미결 액션(pending action)이 없는 때의 시퀀스 다이아그램이다.
도 9는 신속 발신 및 정규 발신(rapid and regular calls)를 보여주는 시퀀스 다이아그램이다.
도 10은 신속 발신 설정을 업데이트하기 위한 시퀀스 다이아그램이다.
도 11은 메인 서버에 대해 에어전트 발신(agent call)을 강요(force)하기 위한 시퀀스 다이아그램이다.
도 12는 보안 동작을 호출(invoke)하기 위한 시퀀스 다이아그램이다.
도 13은 콘솔리데이션 서비스(consolidation service)를 갖는 신속 접촉 시스템의 다른 실시예의 기본 블록도이다.
도 14는 디바이스 구성을 위한 시퀀스 다이아그램이다.
도 15는 디바이스 파라미터 업데이트를 위한 시퀀스 다이아그램이다.
도 16은 신속 접촉 서버의 기동을 위한 시퀀스 다이아그램이다.
도 17은 디바이스 파라미터 업데이트를 대기하기 위한 폴링(polling) 또는 강제 발신(forced call)을 위한 시퀀스 다이아그램이다.
도 18은 미결 파라미터 업데이트 또는 강제 발신 명령의 부재 시의 신속 c발신을 위한 시퀀스 다이아그램이다.
도 19는 미결 파라미터 업데이트 또는 강제 발신이 있는 때의 신속 발신을 위한 시퀀스 다이아그램이다.
도 20은 복수의 콘솔리데이션 서버를 갖는 신속 접촉 시스템의 다른 실시예의 기본 블록도이다.

A. 용어

에이전트(agent) - 본 명세서에 사용된 바와 같이, 에이전트는 영구적이고 잠행하는(persistent and stealthy) 것이 이상적인 소프트웨어, 하드웨어 또는 펌웨어 에이전트이다. 통상적으로, 에이전트는 컴퓨터 또는 다른 전자 디바이스 내의 프로세서 판독 가능 메모리에 상주하는 실행 가능 명령을 포함하거나 이러한 실행 가능 명령으로 이루어진다. 에이전트는 통상적으로 원격 서버와의 통신을 필요로 하는 서비스 기능을 제공한다. 바람직하게는, 에이전트는 부정 조작에 대해 저항성을 갖고(tamper resistant), 데이터 삭제, 방화벽 보호(firewall protection), 데이터 암호화, 위치 추적, 메시지 통지, 및 소프트웨어 개발 및 업데이트와 같은 다양한 서비스를 지원 및/또는 제공하기 위해 인에이블될 수 있다. 에이전트의 예시적인 실시예는 상업적으로 이용 가능한 제품 Computrace Agent™에서 발견된다. Computrace Agent™을 기반으로 하는 기술은 미국 및 기타 국가에서 공개 및 특허되었으며, 그 특허들은 대개 Absolute Software Corporation에 양도되었다. 예를 들면, 미국특허 제5,715,174호; 제5,764,892호; 제5,802,280호; 제6,244,758호; 제6,269,392호; 제6,300,863호; 제6,507,914호; 제7,818,803호; 제7,945,709호 및 관련 외국 특허들을 참조하기 바란다. 에이전트의 영구적인 기능에 대한 세부사항은 미국 특허출원 공개공보 US2005/0216757호 및 US2006/0272020호에 개시되어 있다. 이 특허문헌들의 기술적인 개시 내용은 원용에 의해 본 명세서에 전체적으로 기재된 것과 마찬가지로 전체적으로 통합된다. Computrace Agent™과 동등한 에이전트를 사용하는 것이 가능하며, 또는 덜 바람직하게는 기능이 더 적은 다른 에이전트를 사용하는 것이 가능하다. 본 발명을 위해, 에이전트의 최소 기능 속성(minimal functional attribute)은 전자 디바이스와 모니터링 센터 또는 다른 원격 컴퓨터 또는 서버 간의 통신을 용이하게 할 수 있다. 통신은 일반적으로 에이전트에 의해 개시된다.

디바이스 - 이것은 보호될 전자 디바이스이다. 디바이스의 예는 랩탑, 셀룰러 전화, 개인용 디지털 보조장치, 스마트 폰, 메모리 스틱, 개인 미디어 디바이스, 게이밍 디바이스, 개인용 컴퓨터, 태블릿 컴퓨터, 전자책 및 노트북을 포함한다. 에이전트는 디바이스에 상주하며, 이 디바이스는 에이전트를 위한 호스트로서 지칭될 수도 있다. 디바이스는 또한 클라이언트로서 지칭될 수도 있다.

전자 일련 번호(Electronic Serial Number, ESN) - 디바이스 또는 디바이스 내의 에이전트를 식별하는 고유 번호이다. ESN은 디바이스 내의 메모리 및/또는 레지스터에 저장될 수 있다.

토크, 공개 토큰(Public Token) 또는 인증 토큰 - 이것은 암호화된 ESN이며, 해쉬(hash)에 의해 보호될 수 있다.

신속 접촉 서버(RCS) - 다수의 원격 디바이스가 지연이 있다하더라도 커다란 지연없이 대기 코맨드(awaiting command)를 수신하기 위해 빈번하게 그리고 짧게 접촉하는 컴퓨터 또는 컴퓨터 시스템. RCS는 모니터링 센터의 일부분일 수도 있으며, 고속 접촉 서버 또는 FC 서버로서 알려져 있을 수도 있다. 통상적으로, RCS는 그 어떤 것도 통신 세션에 전용되지 않는 처리 쓰레드의 작은 풀(small pool of processing thread)을 갖는다.

메인 서버 - 원격 디바이스가 대기 코맨드가 있는 경우에 대기 코맨드를 수신하기 위해 덜 빈번하게 그리고 더 길게(RCS에 비하여) 통신하는 가디언 서버(guardian server) 또는 기타 컴퓨터 또는 컴퓨터 시스템. 예컨대, 디바이스에 대해 인터넷 접속이 이용 가능하게 되면, 에이전트는 디바이스의 위치를 보고하고, 존재하는 경우에 소프트웨어 업그레이드를 다운로드하고, 디바이스 상에 있거나 설치되어야 하는 임의의 보안 모듈을 수리(repair)하기 위해 하루에 한번(또는 몇몇의 다른 선택된 적합한 간격으로) 메인 서버에 발신할 수 있다. 발신들 간의 간격은 디바이스가 낮은 위험 영역으로부터 높은 위험 영역으로 이동하거나 또는 디바이스가 분실 또는 도난당하면 수정(예컨대, 감소)될 수 있다. 메인 서버에 대한 통신은 예컨대 인터넷(유선 또는 무선)을 통해, 유선 또는 무선 전화 네트워크를 통해, 케이블을 통해, 또는 위성을 통해 이루어질 수 있다. 메인 서버는 전자 디바이스를 분실하였거나 또는 도난당하였다는 전자 디바이스의 소유주로부터의 통지를 수신할 수 있으며, 그 결과, 메인 서버는 몇몇 종류의 보안 동작을 개시하는 분실된 또는 도난당한 전자 디바이스에게 메시지를 송신할 수 있다. 이 동작은 예컨대 디바이스를 잠그거나, 알람을 울리거나, 데이터를 삭제하거나, 및/또는 위치 정보를 제공하는 것일 수 있다. 이 동작은 디바이스 상의 파일의 리스트를 제공하거나, 디바이스로부터 파일을 검색하거나, 프로세서 기반 도난 방지 특징을 호출하거나, 디바이스 상의 데이터를 암호화하거나, 또는 암호키를 삭제하는 등일 수 있다. 일반적으로, 보호된 디바이스는 메인 서버에의 발신을 개시한다.

모니터링 센터 - 이것은 바람직한 실시예에서는 RCS 및 메인 서버를 포함하는 시스템이다. 모니터링 센터는 이메일 서버를 포함할 수 있거나, 또는 서버 또는 다른 컴퓨터의 그룹 또는 분포일 수 있다. 본 명세서에 개시된 실시예에서, 에이전트는 디바이스 식별 및 위치 정보 및/또는 전달되도록 요구되는 임의의 기타 데이터를 모니터링 센터에 위치되거나 또는 모니터링 센터에 의해 액세스 가능한 원격 전자 저장부에 전송한다. 모니터링 센터의 기능은 전자 소셜 네트워크 서버에 통합되거나 전자 소셜 네트워크 서버와 연관될 수 있다. 모니터링 센터는 전자 디바이스를 분실하였거나 도난당였다는 통지를 소유주로부터 수신할 수 있다. 일반적으로, 보호된 디바이스가 모니터링 센터에 대한 발신을 개시하지만, 모니터링 센터는 예컨대 디바이스가 가능하게 설비된 경우에는 SMS를 통해 보호된 디바이스에 대한 발신을 개시하도록 구성될 수도 있다.

신속 발신(Rapid Call) - 디바이스와 RCS 간의 통신이며, 이것은 디바이스로부터 RCS로의 단방향 통신일 수도 있다. 신속 발신은 RCS로부터의 응답을 발생할 수도 있고 RCS로부터의 응답을 발생하지 않을 수도 있다. 신속 발신은 디바이스와 RCS 간의 짧은 세션인 신속 접촉 세션을 발생할 수 있다. 신속 발신은 빠른 발신(fast call) 또는 FC로서 지칭될 수도 있다.

신속 접촉 세션 또는 짧은 세션 - 이것은 디바이스와 신속 접촉 서버 간에 구축되는 짧은 통신 세션이고, 통상적으로 소수의 패킷 길이이며, 예컨대 4개 또는 5개까지의 패킷으로 되거나 또는 최대 4개 또는 5개의 패킷을 갖는다.

정규 발신 - 디바이스와 메인 서버 간의 통신이며, 그 동안에 일반적으로 더 많은 양의 정보가 교환된다.

예약 정규 발신(Scheduled Regular Call) - 예약된 시간에서 발생하는 정규 발신이다.

즉각적 정규 발신 또는 강제 발신(Forced Call) - RCS와의 통신 동안 요청되고 예약된 정규 발신을 위한 시각 이외의 시각에 발생하는 정규 발신이다.

이하의 상세한 설명에서는 주로 본 발명의 방법 또는 프로세스, 동작의 심볼 표현(symbolic representation), 기능 및 특징에 대하여 설명한다. 이 방법들에 대한 설명 및 표현은, 해당 기술분야의 당업자가 자신의 연구에 대한 요지(substance)를 다른 당업자에게 가장 효과적으로 전달하기 위해 사용되는 수단이다. 소프트웨어에 의해 구현되는 방법 또는 프로세스는 본 명세서에서는 그리고 일반적으로는 원하는 결과를 가져오는 단계들의 자기 모순이 없는 시퀀스(self-consistent sequence)로 생각된다. 이 단계들은 물리량(physical quantity)에 대한 물리적인 취급을 포함한다. 반드시 그런 것은 아니지만 많은 경우에는, 이 양들은 저장, 전달, 결합, 비교, 및 그 밖으로 취급이 가능한 전기 신호 또는 자기 신호의 형태를 취한다. 또한, 하드웨어, 소프트웨어 및 펌웨어 간의 경계(line)는 항상 분명한 것은 아니라는 것을 알 것이며, 해당 기술분야의 당업자라면 소프트웨어로 구현된 프로세스는 마이크로코드(microcode) 및/또는 저장된 프로그래밍 명령어와 같은 부호화된 명령어 형태로, 하드웨어, 펌웨어, 또는 소프트웨어로 구현될 수 있다는 것을 알 것이다. 일반적으로, 달리 명시되지 않는 한, 단수형의 요소는 복수형이 될 수 있고 또 일반성을 잃지 않고서도 그 반대도 가능하다. 도면은 실척으로 도시되어 있지 않다.

상세한 설명의 다수의 부분에서, 본 발명은 도난된 디바이스에 관련하여 설명되고 있지만, 분실된 디바이스에 대해서도 마찬가지로 적용할 수 있다는 것은 당업자에게는 자명할 것이다.

B. 예시 실시예

도 1에는 신속 접촉 시스템(10)의 바람직한 실시예의 기호 블록도(symbolic block diagram)가 도시되어 있다. 시스템(10)은 디바이스(12)와 같은 전자 디바이스를 이들을 신속하게 접촉시키고 이들을 원격으로 제어하기 위한 효율적인 수단을 제공함으로써 보호하도록 되어 있다. 실제로, 시스템에는 수백만 또는 그 이상의 이러한 디바이스(12)가 있을 수 있다. 디바이스(12)는 네트워크(18)에 의해 RCS(30) 및 메인 서버(52)에 접속된다. 네트워크(18)는 인터넷일 수 있거나, 인터넷을 포함할 수 있거나, 전화통신 네트워크일 수 있거나, 전화통신 네트워크를 포함할 수 있다. 디바이스(12)와 네트워크(18) 간의 접속은 유선 또는 무선일 수 있으며, 디바이스는 네트워크에 지속적으로 또는 단속적으로 접속될 수 있다.

각각의 전자 디바이스(12) 내의 에이전트(14)는 디바이스로 하여금 정규적으로 또는 거의 정확하게(approximately) RCS(30)에 발신하도록 한다. RCS(30)는 하나 이상의 프로세싱 코어(34)를 포함할 수 있고 데이터베이스(35) 및 메모리(36)에 연결되며 쓰레드(42)의 고정된 비교적 작은 풀(40) 내의 컴퓨터 판독 가능 명령을 처리하도록 구성된 프로세서(32)를 포함한다. 이 예에서는, 프로세서 코어의 2배의 개수의 쓰레드가 있다. 예컨대 24-코어 프로세서를 갖는 시스템에서, 쓰레드 풀(40) 내에 48개의 쓰레드가 있을 수 있다. 다른 실시예에서는 다른 비율도 가능하다. 콜은 예컨대 약 매 30분마다 또는 임의의 다른 적절한 시간 사이클로 이루어질 수 있다. 몇몇 실시예에서의 콜은 디바이스의 전자 일련 번호(ESN)(16)를 포함하는 하나의 소형 패킷(20)을 RCS(30)의 입력/출력 완료 포트(input/output completion port)(24)에 전송하는 것을 포함한다. ESN(16)은 토큰(17)과 같은 암호화된 형태로 소형 패킷(20)에 포함될 수 있다. RCS(30)에 전송되는 데이터의 하나의 패킷은 각각 통상적으로 총 10-100 바이트를 포함한다. 소형 패킷(20)은 각각의 쓰레드(42)에 의해 처리될 태스크(44)가 된다.

태스크(44)가 RCS(30)에 의해 쓰레드에서 처리되는 때에, 임의의 잔여 헤더 및 체크섬 등은 소형 패킷(20)으로부터 스트립되며(stripped), HTTP 코맨드는 패킷을 전송한 디바이스(12)의 ESN(16)을 드러내기 위해 프로세서(32)에 의해 해석되며, 이것은 ESN(16)이 토큰(17)으로 암호화되어 전송된 경우에는 토큰을 해독하는 것을 포함할 수 있다. 프로세서(32)는 그리고나서 드러내진 ESN(16)에 좌우되어 액션을 취하거나 액션을 취하지 않는다. ESN 및 대응하는 대기 액션은 데이터베이스(35)에 저장될 수 있다. 이러한 액션은 예컨대 세션의 구축을 요청할 수도 있으며, 그 경우에는 이 세션은 짧은 세션일 것이다. 약 700 바이트 또는 그 미만의 데이터가 교환될 수 있는 이러한 신속 접촉 세션에서, RCS(30)는 디바이스와의 비교적 긴 통신을 구축하는 메인 서버(52)에 발신하도록 디바이스(12)에게 명령을 전송할 수 있다. 에이전트는 메인 서버(52)에 비하여 RCS(30)와 통신하기 위해 상이한 각자의 통신 프로토콜을 이용할 수 있다. 예컨대, RCS 통신을 위해 이용한 프로토콜은 메인 서버와 통신하기 위해 사용된 프로토콜에 비하여 상대적으로 짧고 빈번한 통신에 최적화될 수 있다(예컨대, 감소된 핸드세이킹(handshaking) 및 더 작은 메시지 크기를 통해).

예컨대, 디바이스(12)는 도난당한 것으로서 시스템(10)에 플래그(flag)될 수 있다. 디바이스(12)의 소유주는 디바이스(12)의 상태를 도난당한 것으로서 입력하기 위해 메인 서버(52)에 액세스하기 위하여 컴퓨터(61) 또는 또 다른 전자 디바이스를 이용하여 이것을 행할 수 있다. 이러한 디바이스 상태는 메인 서버(52) 내에 있거나 또는 메인 서버(52)에 의해 액세스 가능한 데이터베이스(55) 및 RCS(30)에 의해 액세스 가능한 데이터베이스(35)에 저장된다. 이 경우, 디바이스는, RCS(30)에게 발신할 때에, 메인 서버(52)에게 발신하도록 지시될 것이며, 그리고나서 메인 서버가 디바이스에게 디바이스의 위치를 메인 서버에게 제공하거나, 메인 서버에게 더욱 빈번하게 발신하도록 하거나, 또는 동결 상태(frozen state)에 진입하도록 지시할 것이다. 또 다른 예로서, 신속 접촉 세션은 업데이트된 신속 발신 간격과 같은 업데이트된 파라미터를 RCS(30)로부터 디바이스(12) 전송하기 위해 이용될 수 있다. 이와 달리, 디바이스(12)는 메인 서버(52)와의 발신 동안 전송될 수 있는 메시지를 전송하도록 시스템(10)에 플래그될 수 있다. 디바이스(12)가 도난당한 것으로서 플래그되지 않고, 정규 발신을 요구할 그밖의 것을 위해 플래그되지 않으면, 그 자체가 필수적이지 않고 네트워크 대역폭을 낭비할 것이므로, RCS(30)는 디바이스에게 어떠한 응답도 전송하지 않을 것이다. 그러나, 시스템(10)은 이와 달리 RCS(30)에 대해 HTTP 상태(200)(즉, 메시지 수신 OK) 응답 또는 기타 적절한 확인응답을 디바이스에게 전송하도록 구성될 수 있다. 이와 달리, 디바이스(12)를 대기하는 액션이 없으면, RCS(30)는 접속해제 메시지(disconnect message)를 디바이스에 전송할 수도 있거나 또는 단순하게 접속해제할 수도 있다.

디바이스(12)와 RCS(30) 간의 신속 접촉 세션은 새로운 허가 토큰(authorization token)을 설정하기 위해 이용될 수 있으며, 여기서 디바이스 또는 디바이스 내의 에이전트(14)는 아직 허가 토큰을 갖지 않거나, 유효하지 않은 허가 토큰을 갖거나, 또는 보안 정책의 컨텐츠로 인해 교체된 허가 토큰을 가져야 한다. 신속 접촉 세션은 메인 서버(52)에 대한 다음 예약 정규 발신을 위한 시각을 설정하기 위해 이용될 수도 있다. 신속 접촉 세션은 데이터 삭제 동작을 특별하게 관리하기 위한 메인 서버 또는 암호화를 관리하기 위한 메인 서버와 같은 상이한 메인 서버에 대한 정규 에이전트 발신을 리다이렉트하기 위해 이용될 수 있다. 디바이스(12)가 도난당하였으면, 신속 접촉 세션은 에이전트를 특히 도난당한 디바이스를 처리하는 상이한 메인 서버로 에이전트를 리다이렉트할 수 있다. 신속 접촉 세션은 또한 신속 발신들 간의 시간 간격을 변화시키거나, 또는 신속 발신을 또 다른 RCS로 리다이렉트하기 위해 이용될 수 있다. 신속 접촉 세션은 에이전트(14) 또는 디바이스(12) 내의 필드들의 컨텐츠를 보고하기 위해 이용될 수 있다. 몇몇 경우에, 데이터의 약 4 KB까지가 전달될 수 있다. 신속 접촉 세션 동안 다른 프로세스가 구현될 수 있으며, 주된 요구조건(main requirement)은 세션이 전용의 처리 쓰레드를 요구하기에 충분하지 않은 정도로 짭고, RCS에 신속 발신을 행하는 다른 디바이스(12)에 관련하여 RCS(30)의 효율적인 기능을 현저하게 방해하기에 충분하지 않은 정도로 짧다. 대부분의 시각에서, 디바이스(12)는 응답하지 않는 또는 액션이 요구되지 않는 RCS(30)에 대한 발신을 행한다.

전자 디바이스(12)는 RCS(30)에 의해 지시될 시에 메인 서버(52)에게 발신할 수 있다. 디바이스(12)는 또한 정규적으로, 거의 정규적으로, 반주기적으로, 반무작위로(semi-randomly), 또는 트리거를 검출한 결과로, 또는 요구된 어떠한 프로그래밍 가능한 체계에 따라 메인 서버(52)에게 발신할 수 있다. 메인 서버(52)는 데이터베이스(55) 및 메모리(56)에 연결된 프로세서(54)를 포함하며, 비교적 많은 개수의 쓰레드(58)에서의 컴퓨터 판독 가능 명령을 처리하도록 구성될 수 있다. 쓰레드(58)는 풀의 일부를 형성하지 않는 것이 바람직하다. RCS(30)과 달리, 각각의 세션(60)에 전용되는 적어도 하나의 쓰레드(58)가 바람직하다. 발신은 예컨대 약 24.5 시간마다, 또는 임의의 다른 적절한 시간 사이클로 이루어질 수 있다. 디바이스(12)로부터 메인 서버(52)로의 통신(50)은 통상적으로 RCS(30)에 대한 통신보다 10-10,000배(즉, 1 내지 4 오더의 양) 더 길다. 이러한 통신 세션은 통상적으로 각각 1500 바이트 길이까지의 10 내지 500개의 패킷(51)을 포함한다. 대응하는 쓰레드(58)에 의해 처리된 각각의 세션(60)에서의 태스크(62)는 통상적으로 RCS(30)에서 처리된 태스크(44)에 비하여 크다. 전형적인 시스템에서, 메인 서버(52)에는 8000개 또는 그 이상이 세션이 동시에 유지될 수 있으며, 각각이 적어도 하나의 전용 쓰레드를 갖는다. 세션의 개수는 RAM 또는 메모리(56)의 양에 의해 제한된다.

데이터베이스(55)는 각각의 디바이스(12)에 통신될 태스크, 업데이트 및 코맨드를 저장한다. 디바이스(12)의 소유주 또는 관리자가 디바이스의 상태의 기록을 변경하거나, 즉각적 정규 발신을 강요하거나, 또는 디바이스의 현재 파라미터를 획득하는 등의 필요가 있을 때마다, 이들 모두는 네트워크(18)에 접속된 컴퓨터(61) 또는 기타 적절한 디바이스를 이용하여 행해질 수 있다. 데이터가 디바이스(12)로부터 삭제되어야 하거나, 또는 디바이스가 동결되어야 하면, 이들 코맨드 또한 컴퓨터(61)를 통해 메인 서버(52)에 통신될 수 있다. 디바이스는 그룹화될 수 있으며, 신속 발신은 예컨대 컴퓨터(61)를 통해 이러한 디바이스의 그룹의 관리자에 의해 인에이블 또는 디스에이블되도록 통합적으로 요청될 수 있다. 메인 서버(52)는 대상으로 하는 디바이스(12)의 신속 발신 상태에 대한 정보를 컴퓨터(61)에게 송신할 수 있다. 이러한 정보는 디바이스(12)가 신속한 발신을 위해 현재 인에이블되는지의 여부, 디바이스가 현재 발신중인지 아니면 오프라인인지의 여부, 및 최종 신속 발신의 시각일 수 있다. 메인 서버(52)는 RCS 내의 데이터베이스(35)가 자신의 후속 신속 발신 동안 디바이스를 위한 액션으로 업데이트될 수 있도록 시시때때로 RCS(30)와 통신한다. 예컨대, RCS의 데이터베이스(35)는 디바이스(12)를 메인 서버(52)에게 발신하도록 RCS에게 지시하도록 업데이트될 수 있거나; 디바이스는 즉각적으로 또는 메인 서버에 대한 다음 번의 정규적으로 예약된 발신 전의 몇몇 다른 시점에서 메인 서버에게 발신함으로써 이러한 명령에 응답할 수 있다.

디바이스(12)와 메인 서버(52) 간의 단일 통신은 병렬 실행 쓰레드로 실행될 수 있는 복수의 태스크가 생성되게 할 수 있다. 예컨대, 메인 서버(52)와의 단일 통신(50)의 결과로 2개, 3개 또는 그 이상의 전용 쓰레드(58)가 이용될 수 있다.

메인 서버(52)는, 디바이스의 위치를 서버에게 제공하거나, 데이터를 삭제하거나, 디바이스의 부품의 몇몇 또는 전부에 대한 식별을 전송하거나, 또는 임의의 종류의 보안 동작을 취하도록 디바이스에게 명령하기 위해 서버로부터의 메시지를 포함할 수 있는, 디바이스(12)와의 메인 통신을 담당한다. 메인 서버(52)는 또한 디바이스(12)에게 업그레이드를 송신할 수 있다. 메인 서버(52)가 비교적 긴 통신을 받아들이고, 세션(60)이 얼라이브 상태(alive)로 유지되고 자신의 콘텍스트 또는 상태가 유지되는 비교적 긴 태스크를 수행하므로, 각각의 통신 세션을 위해 하나 이상의 전용 쓰레드가 이용된다. 이와 달리, RCS(30)는 상태를 유지하지 않거나 또는 최소 트랙의 상태를 유지하며, 비전용 쓰레드가 RCS에서 이용될 수 있다. 이것은 또한 RCS(30)에 의해 요청될 수 있는 신속 접촉 세션 및 신속 발신 둘 모두에 대해서도 그러하며, 이러한 신속 접촉 세션에서 디바이스(12)에 의해 RCS에 전송되는 후속 패킷은 임의의 쓰레드(42)에 의해 처리될 수 있다.

신속 접촉 세션이 사전에 정해진 상태를 갖도록 하기 위해, 예컨대 516 바이트의 전체 어레이를 판독하고 기록하는 것이 지원되어야 하며, 이로써 모든 필수적인 수정이 RCS(30) 내에서 수행된다. 에이전트(14)는 안전한 신속 접촉 세션 동안의 이러한 설정의 변경을 허용하거나, 또는 RtlCopyMemory Windows™ API(어플리케이션 프로그래밍 인터페이스)가 설정을 메모리에 기입하고 이들을 설정 어드레스에 카피하기 위해 이용될 수 있다. 전자의 접근법은 단지 하나의 트랜잭션을 요구하기 때문에 더 빠르다. 후자의 접근법에서, 에이전트는 신속 접촉 세션이 개시하기 전에 RtlCopyMemory 루틴의 어드레스를 검출하여야 한다.

디바이스(12)로부터 RCS(30)로의 신속 발신 및 이 둘 간의 신속 접촉 세션은 메인 서버(52)에 대한 정규 발신보다 훨씬 더 간단하며, 더 짧은 수 오더의 크기일 수 있다. 이들 신속 발신의 목적은 RCS(30)가 디바이스의 온라인 이용 가능성에 대해 알게 하도록 하고, 필요한 경우 신속 접촉 시스템(10)에게 디바이스(12)와 메인 서버(52) 간의 정규 발신을 즉시 구축하기 위한 수단을 제공하도록 하기 위한 것이다. 예컨대, 도난된 전자 디바이스는 신속 접촉 시스템(10)에서 및 보다 구체적으로는 RCS(30)와 메인 서버(52)에서 이와 같이 플래그될 수 있다. 도난당한 디바이스(12)가 RCS(30)에 발신하는 때에, 데이터 삭제 코맨드, 잠금 코맨드 등을 포함할 수 있는 더욱 포괄적인 명령을 위해 메인 서버(52)에게 즉각적으로 발신하도록 RCS에 의해 지시될 것이다. 이것은 길이가 긴 태스크로 RCS(30)를 막는(clogging) 것을 방지하면서, 메인 서버(52)에게 발신할 디바이스의 다음 예약 시간까지 디바이스가 대기하여야 한다면 디바이스가 보통은 겪게 될 대기 시간을 제거한다. 쓰레드 풀(40) 내의 비교적 적은 개수의 쓰레드(42)는 많은 수의 디바이스(12)로부터의 비교적 많은 수의 작은 태스크(44)를 처리하는데 적합하거나, 상태가 유지될 필요가 없는 통신에 적합하거나, 또는 세션에 전용되는 쓰레드를 필요로 하지 않고서도 추적될 수 있는 상태의 예측 가능한 소수의 값이 있는 경우에 적합하다.

쓰레드 풀(40)은 쓰레드 생성이 프로세서 사용의 면에서 특별히 저렴하지 않기 때문에 RCS(30)에서 이용되며, 준비-대기 쓰레드(ready-waiting thread)를 갖는 것은 인입 태스크(incoming task)(44)의 할당 및 처리를 특히 쓰레드의 개수가 최적화된 경우에 더욱 효율적이 되게 한다. RCS(30)에서의 프로세서(32)의 효율을 최대화하기 위해, 작은 패킷(20)을 처리하기 위한 코드는 최소로 유지되어야 하는 것이 이상적이며, 정규 통신을 처리하기 위해 이용된 메인 서버(52)에서의 코드와 별도의 것이어야 한다. 이것은 RCS(30)로 하여금 운영 시스템 리소스 및 네트워크 처리량에 좌우되어 가능한 한 다수의 동시 발신을 처리하도록 한다.

디바이스(12)와 RCS(30) 간의 통신은 쓰레드로 하여금 임의의 I/O 동작의 처리를 기동하도록 하는 완료 포트(24)를 이용한다. 모든 세션 콘텍스트(session context)가 쓰레드-안전 사전(thread-safe dictionary)에 유지되고, 대응하는 I/O 동작이 완료되는 즉시 액티브로 된다. 세션 콘텍스트는 현재의 세션 상태를 유지하며, 이것은 RCS(30)가 현재 세션으로 지속되도록 한다. 현재 세션의 처리 동안, 데이터베이스(55)에의 통신을 포함한 모든 블로킹 동작이 방지되거나, RCS(30) 내의 다른 특정한 쓰레드 또는 쓰레드 풀에 오프로드(offload)되어, 신속 접촉 세션을 위해 사용된 쓰레드(40)가 가능한 한 신속하게 또 다른 완료된 I/O 동작에 이용 가능하게 되어야 한다.

RCS(30)는 킵-얼라이브 세션 및 논-킵-얼라이브 세션(keep-alive and non-keep-alive session) 둘 모두를 지원하며, 세션을 식별하기 위해 세션 ID를 사용한다. 현재 세션 리스트를 제어하기 위해, 특별한 와치독 쓰레드(special watchdog thread)는 만료된 논-킵-얼라이브 세션에 대한 체크를 잠시 동안 수행한다.

I/O 및 신속 접촉 세션 처리 쓰레드 이외에, RCS(30)는 특정한 포트를 통한 TCP 통신을 이용하여 특별한 쓰레드에 대해 외부 데이터베이스(예컨대, RCS(30)로부터의 별도의 서버에서 구현되는 경우에는 데이터베이스 35)로부터 발신되도록 이용할 수 있는 콜백 인터페이스(callback interface)를 가져야 한다. RCS(30)는 또한 성능 카운터, 리포팅, 시동 동안의 외부 데이터베이스를 질의(querying), 로깅(logging) 등을 위한 지원을 가질 수 있다.

도 2를 참조하면, 디바이스(12)로부터 RCS(30)에 전송된 작은 패킷(20)의 예가 도시되어 있다. 작은 패킷(20)은 예컨대 인터넷 프로토콜 헤더, TCP 헤더, 및 다양한 체크섬을 포함할 수 있는 헤더부(63)를 갖는다. 송신을 위해 사용된 프로토콜에 좌우되어, 헤더부(63)는 20 바이트 길이이어도 된다. 헤더부(63)에 후속하여, POST 요청과 같은 HTTP 요청(64)으로 형성되는 데이터부와, 디바이스(12)의 ESN(16)을 포함할 수 있는 식별부(65)가 있다. 특정한 경우에 따라서는, HTTP 요청(64)은 예컨대 156 바이트 길이로 될 수 있으며, 식별부(65)는 24 바이트 길이로 될 수 있다. 전체적으로, 패킷(20)은 200 바이트 길이로 될 수 있다. 선택된 구성에 좌우되어, 다른 실시예에서의 작은 패킷은 상이한 부분 길이 및 상이한 전체 길이를 가질 수 있다. 주요 조건은 특히 메인 서버(52)와의 통신 패킷(51)에 비교할 시에 패킷(20)이 작은 패킷이고, 발신하고 있는 디바이스(12)를 식별하기에 충분한 최소의 정보를 포함하고 있다는 것이다.

식별부(65)는 디바이스(12)를 위해 ESN에 기초하여 발생되고 RCS(30)에 저장되는 공개 통신일 수 있다. RCS(30)는 토큰을 입증(validate)하고 이 토큰을 ESN으로 변환하기 위해 키를 저장한다.

예컨대, 작은 패킷(20) 내의 데이터부(즉, HTTP 요청(64) 및 식별부(65))는 다음과 같이 될 수 있다:

도 3을 참조하면, 디바이스(12)로부터 메인 서버(52)로 또는 그 반대로 전송된 정규 패킷(51)의 예가 도시되어 있다. 정규 패킷(51)은 예컨대 예컨대 인터넷 프로토콜 헤더, TCP 헤더 및 다양항 체크섬을 포함할 수 있는 헤더부(67)를 갖는다. 송신을 위해 사용된 프로토콜에 좌우되어, 헤더부(67)는 20 바이트 길이이어도 된다. 헤더부(67) 다음에는, 디바이스(12) 내의 콤포넌트의 상세한 식별, 디바이스의 위치, 디바이스 상에 저장된 파일, 디바이스의 상황, 디바이스 상에 설치된 소프트웨어의 세부사항 등뿐만 아니라 디바이스의 ESN(16)을 포함할 수 있는 데이터부(68)가 있다. 특정한 경우에 좌우되어, 패킷(51)의 데이터부(68)는 예컨대 약 1500 바이트 길이로 될 수 있다. 주요 요점은 특히 RCS(30)에 대한 통신 패킷(20)에 비교할 시에 패킷(51)이 커도 되고 일반적으로 크며, 포괄적 정보 및 코맨드를 포함할 수 있다는 점이다.

도 4를 참조하면, 디바이스(12)를 위한 신속 발신 기능을 구축하기 위해 시스템(10)에 의해 취해질 수 있는 프로세스를 개략적으로 도시하고 있으며, 그 경우 디바이스는 RCS(30)에 대해 신속 발신을 행하기 위해 아직 구축되지 않았지만, 메인 서버(52)에 대한 발신을 행하기 위해 구축되어 있다. 신속 접촉을 위해 디바이스(12)를 설정하는 액션 아이템은 메인 서버(52) 내의 데이터베이스(55)에 사전에 플래그된다. 단계 70에서, 메인 서버(52)에 대한 정규 발신이 디바이스(12)에 의해 이루어진다. 단계 72에서, 디바이스(12)가 RCS(30)에게 발신하는 것을 개시하기 위해 메인 서버로부터 코맨드를 수신하며, RCS의 URL뿐만 아니라 에이전트(14)를 위한 임의의 필수적인 업그레이 코드 또한 디바이스에 제공된다. 신속 발신 레이트 또한 연속적인 신속 발신들 간에 경과하여야 하는 시간 간격의 형태로 디바이스(12)에 제공될 수 있다. 디바이스(12) 내의 에이전트(14)는 단계 74에서 RCS(30)에 대한 신속 발신을 행하기 위해 디바이스를 인에이블시킨다. 예컨대, 이것은 신속 발신을 행하여야 한다는 것을 나타내기 위해 에이전트 내의 비트 플래그를 설정함으로써 실시될 수 있다. 단계 76에서, 디바이스(12)는 RCS(30)에 대해 신속 발신을 행한다. 단계 78에서, RCS(30)는 신속 접촉 세션이 디바이스(12)로 오픈되어야 하는지를 판정한다. 신속 접촉 세션이 오픈되지 않으면, 예컨대 정규 발신이 행해질 즉각적인 필요가 없다면, 단계 80에서는, 디바이스(12) 내의 에이전트(14)가 메인 서버(52)에 대한 예약 정규 발신을 행할 때인지를 판정한다. 이러한 예약 정규 발신의 때가 아니면, 프로세스는 단계 76으로 되돌아가며, 이 단계에서 신속 발신을 위한 설정된 시간 간격이 경과된 후에 RCS(30)에 대해 후속 신속 발신이 행해진다. 예약 정규 발신의 때이면, 단계 82에서는 메인 서버에 대해 정규 발신이 이루어진다. 단계 78로 되돌아와서, 신속 접촉 세션이 RCS(30)로 오픈될 것이면, 단계 84에서는 RCS는 디바이스(12)가 세션을 오픈하도록 요청한다. 신속 접촉 세션 동안, 단계 86에서, 즉각적인 정규 발신이 이루어지지 않으면, 프로세스는 단계 80으로 되돌아가고, 이 단계에서, 에이전트는 예약 정규 발신이 그래도 행해질 것인지를 판정한다. 그러나, 단계 86에서, 신속 접촉 세션 동안, 디바이스(12)가 메인 서버(52)에게 발신할 것이며, 프로세스는 단계 82로 이동하고, 이 단계에서 디바이스가 메인 서버에 대한 즉각적인 발신을 행한다.

반대로, 디바이스(12)의 소유주 또는 관리자는 신속 접촉 특징이 디스에이블되었다는 것을 메인 서버(52)에게 알려줄 수 있다. 이 정보는 그리고나서 메인 서버(52)로부터 RCS(30)에 전달될 것이며, RCS는 후속의 신속 발신 동안 RSC에게 발신하는 것을 중지하도록 디바이스에게 코맨드가 전송될 신속 접촉 세션의 구축을 요청할 것이다.

디바이스(12)가 도난당한 것으로 보고되는 때에, 메인 서버(52)에게의 디바이스의 발신 시에, 메인 서버에게 더욱 빈번하게, 예컨대 매 15분마다 또는 몇몇 다른 적합한 간격으로, 발신하도록 지시된다. 디바이스(12)가 메인 서버에게 보다 자주 발신할 것이므로, RCS(30)에게 발신할 필요가 없을 것이고, 이로써 에이전트(14)는 RCS에게 발신하는 것을 중지하도록 지시될 수 있다.

도 5를 참조하면, 신속 발신을 수신할 시에 RCS(30)에서 발생하는 프로세스의 흐름도가 도시되어 있다. 단계 90에서, RCS(30)가 신속 발신을 수신하고, 그리고나서 단계 92에서, 신속 발신에서 수신된 ESN에 기초하여, 해당 ESN을 갖는 디바이스(12)에 대해 어떠한 업데이트가 있는지를 판정한다. 업데이트는 새로운 RCS에의 발신(new RCS to call), 새로운 메인 서버에의 발신(new main server to call), 새로운 발신 시각 또는 간격 등일 수 있다. 요구된 업데이트가 없으면, 단계 94에서는, RCS(30)가 신속 발신을 무시하고 응답하지 않으며, 프로세스는 단계 96에서 종료된다. 그러나, 디바이스에 대한 업데이트가 있으면, 단계 98에서, RCS(30)는 디바이스가 세션을 오픈하도록 요청하고, 그 동안 단계 99에서, RCS가 디바이스에게 업데이트(들)를 전송한다. 업데이트가 전송된 후, 프로세스는 단계 96에서 종료된다. 이 전체적인 프로세스는 각각의 후속 신속 발신으로 반복된다.

C. 인증 토큰

에이전트(14)는 RCS(30)과 2가지 모드, 즉 에이전트가 RCS(30)에 의해 생성되고 디바이스(12)에게 역으로 전송한 공개 RCS 인증 토큰(17)을 갖거나 또는 공개 RCS 인증 토큰에 대한 액세스를 가질 때의 인증된 모드(authenticated mode)와, 에이전트가 이러한 토큰(17)을 갖지 않을 때 또는 변경이 이루어지는 때 중의 어느 하나에 대한 인증되지 않은 모드(unauthenticated mode)로 통신할 수 있다. 에이전트(14)가 토큰(17)을 갖거나 토큰(17)에 대한 액세스를 가진다면, 리부트 동안 지속적으로 복원될 수 있도록 레지스트리에 저장될 수 있다. 인증된 모드에서, 토큰(17)이 이미 에이전트의 아이덴티티 및 그에 따라 디바이스 아이덴티티의 암호화된 표현일 것이고, 이것이 RCS(30)에만 알려질 것이므로, 데이터는 암호화되지 않은 상태로 전송될 수 있다.

에이전트(14)가 토큰(17)을 갖지 갖고 토큰(17)에 대한 액세스도 갖지 않는다면, 에이전트(14)는 데이터를 갖지 않는 패킷을 전송하고, RCS(30)로부터의 응답으로 오픈 세션 코맨드(open session command)를 수신한다. RCS가 토큰을 인증할 수 없거나 또는 토큰이 인증되었지만 요구된 몇몇 변경이 있고 에이전트의 설정 내의 데이터를 변경함으로써 에이전트의 행위 및/또는 정책이 업데이트되어야 한다면, 동일한 응답이 주어질 것이다. 오픈 세션 코맨드를 수신한 후, 에이전트(14) 및 RCS(30)는 암호화키 및 초기화 벡터(initialization vector)를 구축하고, 통신을 안전하게 하기 위해 이들을 이용한다. 암호화된 세션 동안, 디바이스의 ESN(16)은 RCS(30)에 의해 데이터베이스(35)로부터 검색될 수 있고, 미결 액션(pending action)에 대해 체크될 수 있으며, 어떠한 미결 액션이 있으면, 예컨대 발신할 메인 서버의 URL, 다음 정규 발신 시각, 발신할 RCS의 URL, RCS에 대한 디폴트 콜백 시각(default callback time) 등과 같은 필요한 변경이 필요에 따라 이루어질 수 있다. 보안 토큰(17) 또한 발행될 수 있다. 이들 변경은 암호화된 세션이 에이전트(14)의 초기 구축을 RCS(30)에게 발신하는 것으로 한다면 널(null) 또는 디폴트 값으로부터 변경될 수 있다. 새로운 토큰이 발생되면, 에이전트는 이 토큰을 후속하는 신속 발신에 사용하기 위해 레지스트리에 저장한다.

토큰(17)을 발생하기 위해, RCS(30)는 디바이스의 ESN을 메시지 및 RCS 특정 인증 태그(예컨대, 컴퓨터 이름, 레지스트리로부터의 데이터, 작업중인 폴더명 등)로서 획득하고, 한 달에 1회와 같은 특정한 스케줄에 기초하여 RCS에 의해 생성되고 RCS 레지스트리에 저장된 RCS 암호화키를 이용하여 ESN을 암호화한다. 토큰(즉, 암호화된 ESN)은 그 후 후속하는 신속 발신에서 RCS에 역으로 전송될 데이터로서 디바이스(12)에 전송된다. RCS(30)가 후속 신속 발신에서 데이터를 수신할 때, RCS(30)는 이 데이터를 디바이스(12)의 ESN을 드러내기 위해 인증 태그를 이용하여 암호해독한다. RCS의 인증 태그가 변경되는 때마다, 모든 디바이스(12)로부터의 신속 발신은 모든 토큰(17)이 갱신(renew)될 때까지 신속 접속 세션의 설립을 발생할 것으로 예상될 것이다.

도 6을 참조하면, 토큰(17)을 최초로 구축하거나 또는 기존의 토큰을 변경하기 위한 프로세스를 위한 신속 접촉 시스템(10)의 흐름도가 도시되어 있다. 단계 110에서, 에이전트(14)는 RCS(30) 또는 메인 서버(52) 둘 중의 어느 하나에 대한 발신을 행할 때인지를 체크한다. 단계 112에서 결정된 바와 같이, 발신을 행할 때가 아니면, 프로세스는 단계 110으로 복귀하여 이들 서버 중의 어느 하나에 대한 발신을 행할 때인지를 추후에 체크하기 위해 단계 110으로 복귀한다.

단계 112에서, 발신을 행할 때이면, 에이전트는 이루어져야만 하는 신속 발신인지를 단계 114에서 판정한다. 신속 발신이 아니면, 단계 116에서 메인 서버에 대해 정규 발신이 이루어진다. 단계 114에서, 신속 발신이 이루어져야 하면, 에이전트는 토큰(17)에 대한 액세스를 갖는지를 단계(120)에서 판정한다. 에이전트(14)가 토큰(17)에 대한 액세스를 갖지 않는다면, 에이전트는 단계 122에서 RCS(30)에게 빈 패킷(즉, 데이터를 갖지 않거나, ESN을 갖지 않거나, 널 ESN을 갖는)을 전송한다. 그러나, 에이전트(14)가 토큰(17)에 대한 액세스를 갖는다면, 에이전트는 단계 124에서 RCS에게 토큰을 통하는 패킷(20)을 전송한다. 토큰(17)이 전송된 후, 에이전트(14)는 단계 126에서 통신이 종료되었는지를 판정한다. 통신의 종료는 에이전트(14)에게 확인 응답 또는 접속해제 코맨드를 전송하거나 또는 무응답함으로써 RCS(30)에 의해 나타내질 수 있다. 단계 126에서, 통신의 종료가 아니면, 에이전트(14)는 단계 128에서 RCS(30)로부터 "오픈 세션" 코맨드를 수신하였는지를 판정한다. 오픈 세션 코맨드를 수신하지 않았다면, 에이전트(14)는 RCS(30)로부터 오픈 세션 코맨드를 수신하고, 단계 131에서 세션을 연다. 에이전트는 또한 단계 122 후에 단계 128에 도달할 수 있으며, 이 단계에서는 RCS에게 빈 패킷을 전송한다. 단계 132에서, 에이전트는 유효 암호화 DLL이 디바이스 내에 존재하는지를 판정하며, 존재한다면, 단계 134에서 에이전트와 RCS 간에 키가 교환된다. 단계 136에서 판정된 바와 같이, 키 교환이 성공적이지 않으면, 에이전트는 단계 130에서 RCS(30)로부터 접속해제한다. 단계 136에서 판정된 바와 같이, 키 교환이 성공적이면, 에이전트는 단계 138에서 RCS에게 패킷을 전송한다. 전송된 패킷은, 이용 가능한 경우, 디바이스의 ESN, 디바이스가 발신하는 메인 서버의 URL, 메인 서버에 대한 다음 발신 시각, RCS의 URL, RCS에게 발신할 간격을 포함한다. 이에 응답하여, RCS(30)은 업데이트된 데이터(필요한 경우) 및 새로운 토큰(17)을 디바이스(12)에게 전송한다. 단계 140에서, 에이전트가 새로운 데이터를 수신하면, 단계 142에서 디바이스 설정을 업데이트한다. 그 후 또는 단계 140에서 에이전트에 의해 수신된 새로운 데이터가 없으면, 에이전트(14)는 단계 144에서 디바이스(12)에 새로운 인증 토큰(17)을 저장한다. 이에 후속하여, 단계 130에서 에이전트가 접속해제한다.

정상적으로는, 암호화 DLL 및 공개 RSA 키가 RCS(30)와의 신속 접촉 세션 동안 디바이스에 제공될 것이라는 것에 유의하기 바란다. 이들 중의 어느 하나가 제공되지 않거나, 또는 암호하 DLL이 로딩될 수 없다면, 에이전트는 즉각적으로 메인 서버(52)에게 자동으로 발신하도록 구성될 수 있다. 이와 달리, 에이전트는 일상적인 것처럼 동작하고, 스케줄에 따라 메인 서버에게 발신할 수도 있다.

D. 시퀀스 다이아그램

도 7을 참조하면, 메인 서버(예컨대, 가디언 서버)에 대한 정규 발신이 가능한 디바이스 상에서 신속 발신을 가능하게 하기 위한 시퀀스 다이아그램이 도시되어 있다. 에이전트로부터 메인 서버로의 정규 에이전트 발신(200)의 결과로, 디바이스와 메인 서버 간에 구축되는 통신 세션 동안 신속 발신(FC, 또는 고속 발신) 특징이 구축된다(202). 신속 발신 특징의 구축에 후속하여, 에이전트는 RCS(30)에 대한 신속 발신을 행한다(204). RCS는 할 것이 아무 것도 없을 때에 확인응답으로 응답한다(206). 얼마 후, 에이전트는 추가의 신속 발신을 행하고(208), 여전히 할 것이 아무 것도 없을 때에 확인응답을 재차 수신한다(210).

도 8을 참조하면, 디바이스를 위한 미결 액션이 없을 때의 시스템 동작을 위한 시퀀스 다이아그램이 도시되어 있다. 에이전트는 HTTP 요청을 RCS에게 포스팅한다(220). RCS는 할 것이 아무 것도 없을 때에 확인응답으로 응답한다(222). 잠시 후(224), 에이전트는 추가의 신속 발신을 행하며(226), 여전히 할 일이 아무 것도 없을 때에 확인응답을 재차 수신한다(228).

도 9를 참조하면, 정규 발신이 신속 발신을 위해서도 구성되는 에이전트에 의해 이루어질 때에 발생하는 이벤트를 보여주는 시퀀스 다이아그램이 도시되어 있다. 에이전트는 HTTP 요청을 RCS에 호스팅한다(250). RCS는 할 일이 아무 것도 없을 때에 확인응답으로 응답한다(252). 잠시 후, 에이전트는 추가의 신속 발신을 행하며(254), 여전히 할 일이 아무 것도 없을 때에 확인응답을 재차 수신한다(256). 다음으로, 스케줄된 정규 발신 시각에서, 세션의 구축 및 정규 발신에 연관된 데이터의 교환을 수반하는, 메인 서버에 대한 정규 발신의 시각이 된다(260). 정규 발신 후, 에이전트는 RCS에 대한 신속 발신을 행하는 것으로 되돌아간다(264).

도 10을 참조하면, 신속 발신 설정이 RCS에 대한 발신 동안 업데이트될 수 있 방법을 보여주는 시퀀스 다이아그램이 도시되어 있다. 먼저, 에이전트는 HTTP 패킷을 RCS에게 전송한다(270). RCS는 세션을 오픈하라는 요청으로 응답한다(272). 그리고나서, 에이전트는 현재 설정을 RCS에게 전송하며(274), 그에 후속하여 RCS가 업데이트된 설정을 역으로 에이전트에게 전송한다(276). 그리고나서, 세션이 종료된다. RCS가 신속 발신을 스위치오프하기 위한 설정을 전송하지 못하는 것으로 가정하면, 통상적인 타임아웃 간격이 경과한 후에, 에이전트는 다시 RCS에게 발신한다(278).

도 11을 참조하면, 메인 서버에 대한 에이전트 발신을 강요할 수 있는 방버을 보여주는 시퀀스 다이아그램이 도시되어 있다. 이것은 예컨대 단지 5개의 패킷을 이용하여 달성된다. 먼저, 에이전트는 HTTP 패킷을 RCS에게 전송하며(300), 그리고나서 RCS는 세션을 오픈하라는 요청을 에이전트에게 전송한다(302). 그리고나서, 에이전트는 자신의 설정을 RCS에게 전송하며, RCS가 업데이트된 설정을 존재하는 경우에 역으로 전송하고(306), 그리고나서 에이전트가 즉각적으로 메인 서버에게 발신하게 하는 코맨드를 역으로 전송한다(308). RCS와의 신속 접속 세션이 접속해제된 후, 에이전트는 자신의 정상 스케줄 이외에 즉각적으로 메인 서버에게 발신하며(310), 메인 서버와의 세션을 구축한다. 메인 서버와의 세션이 종료되는 때에, 에이전트는, 신속 발신 간격이 경과한 후에, 평상시처럼 RCS에게 발신한다(312).

도 12를 참조하면, 보안 액션의 성능을 보여주는 시퀀스 다이아그램이 도시되어 있다. 전술한 바와 같이, RCS에 대해 신속 발신(320)이 행해지며, 그 동안 메인 서버에 대한 즉각적인 발신을 개시하기 위해 에이전트에게 코맨드가 전송된다(322). 이것은 메인 서버에 대한 발신을 강요하기 위해 특정한 에이전트를 위한 RCS에서 플래그가 설정되었기 때문이다. 메인 서버와의 세션(330) 동안, 에이전트는 디바이스로부터 데이터를 삭제하는 것을 개시하기 위해 명령을 수신한다(334). 메인 서버와의 세션이 종료되고, 디바이스는 데이터 삭제 동작으로 지속된다. 신속 발신들 간의 시간 간격은 데이터 삭제 동작이 종결된 후에 경과한다. 에이전트에 의해 취해질 또 다른 높은 우선순위 액션이 있으므로, RCS에 대한 후속의 신속 발신(340) 동안, 메인 서버에게 발신하라는 코맨드(342)가 RCS로부터 에이전트에게 다시 한번 송신된다. 이 예에서, 디바이스를 동결하라는 코맨드(346)가 메인 서버에 대한 발신 동안 전송된다(344). 디바이스가 동결된 경우에도, 여전히 RCS에게 발신하는 능력이 보유되며, 이것은 발신간 간격(inter-call interval)(224)이 경과한 후에도 그러하다. 이 때, 에이전트에 대한 아웃스탠딩 액션(outstanding action)이 없고, RCS에서의 플래그가 리셋되므로, 메인 서버와의 세션이 요청되지 않는다.

E. 콘솔리데이션 서버를 갖는 추가의 실시예

도 13을 참조하면, 신속 접속 시스템의 다른 실시예가 도시되어 있다. 이 도면에는 라우터(380)를 통해 복수의 RCS(FC 서버)(30)에 접속된 복수의 디바이스(12)를 도시하고 있다. 메인 서버(52)는 CTSrv로서 도시되어 있다. 고객으로 하여금 신속 접촉 관련 정보를 볼 수 있도록 하고 신속 발신 특징을 인에이블 및 디스에이블하도록 하는 웹 어플리케이션을 구현하는 고객 센터 서버(CC)(390)가 도시되어 있다. 고객 센터 서버는 어느 디바이스가 신속 접촉이 인에이블되어 있고, 어느 디바이스는 그렇지 않다는 것을 보여줄 수 있다. 고객 센터 서버는 각각의 디바이스로부터의 마지막 신속 발신의 시각을 보여줄 수 있고, 최근에 발신한 디바이스를 온라인이 되기 더 쉬운 것처럼 강조할 수 있다. CC는 메인 서버에 대한 정규 발신을 가용하기 위해 이용될 수 있다. CC는 어느 디바이스가 아웃스탠딩 파라미터 업데이트(outstanding parameter update) 또는 이들에 대한 강제 에이전트 발신 액션(force agent call action)을 갖는지를 보여줄 수 있고, 이미 완료된 액션의 히스토리를 보여줄 수 있다. 사용자가 신속 접촉이 인에이블된 디바이스 상에 엔드 유저 메시지(End User Message), 디바이스 프리즈(Device Freeze) 또는 데이터 딜리트(Data Delete)를 요청하면, CC는 디바이스가 다음 번 발신 시에 디바이스가 정규 에이전트 발신을 행하여야 한다는 것을 콘솔리데이션 서비스(400)(아래를 참조)에 통지할 것이다.

EMS(395)는, 또한 웹 서비스로서 구현되는, CC(390)의 기능과 유사한 몇몇 기능을 갖는 ESN 관리 서버이다. 이것은 사용자로 하여금 하나의 컴퓨터 또는 컴퓨터의 그룹 상에서 동시에 신속 접촉 관련 파라미터를 설정하도록 할 것이다. 컴퓨터는 공통 순차(common order)로 될 수 있거나 또는 공통 계정(common account)에 있을 수 있다. EMS(395)는 메인 서버로의 강제 발신(forced call)을 요청하기 위해 이용될 수 있다. EMS(395)는 어느 디바이스가 신속 접촉이 인에이블되었는지와 어느 디바이스는 그렇지 않은지를 보여줄 수 있다. EMS(395)는 각각의 디바이스로부터 최종 신속 발신의 시각을 보여줄 수 있고, 최근에 발신한 디바이스를 온라인이 되기 더 쉬운 것으로 강조할 수 있다. EMS는 어느 디바이스가 아웃스탠딩 파라미터 업데이트 또는 이들에 대한 강제 에이전트 발신 액션을 갖는지를 보여줄 수 있고, 이미 완료된 액션의 히스토리를 보여줄 수 있다.

RCS는 특정 에이전트가 메인 서버에 대한 정규 발신을 행할 필요가 있는지의 여부에 대하여 콘솔리데이션 서비스(400)로부터 정보를 획득한다. 디바이스가 발신할 때, RCS는 디바이스에게 이 정보를 전송하고, 발신 및 이루어진 어떠한 변경에 대하여 콘솔리데이션 서비스에 통지한다.

콘솔리데이션 서비스(400)는 에이전트의 파라미터를 업데이트하기 위한 어떠한 새로운 요청에 대해 RCS에게 통지한다. RCS가 완료된 에이전트 파라미터 변경에 대하여 콘솔리데이션 서비스에 통지할 때, 콘솔리데이션 서비스는 변경에 대한 정보를 외부 데이터베이스(410)에 기입한다. 콘솔리데이션 서비스는 또한 CC 및 EMS 둘 모두에게 이것에 접속되는 RCS에 대한 상태 정보 및 특정 디바이스가 RCS에 대해 발신한 최종 시각과 같은 정보를 제공한다. 작은 신속 접촉 시스템에 대해서는, 콘솔리데이션 서비스는 단지 인터페이스 및/또는 API로서 구현될 수 있지만, 대형 시스템에 대해서는 독립 서버(standalone server)로서 구현되는 거이 더 좋다.

신속 접촉 데이터베이스(405)는 디바이스의 다음 발신 시에 업데이트될 필요가 있는 디바이스에 대한 파라미터 업데이트의 리스트를 저장한다. RCS가 기동될 때에, RCS는 이들의 로컬 캐시(35)를 직접 시드(seed)하기 위해 신속 접촉 데이터베이스(405)에게 질의한다. CC 및 EMS는 어느 액션이 완료되었는지에 대한 정보를 직접 얻기 위해 데이터베이스(410)에게 질의한다. 데이터베이스(415)는 또한 EMS 및 CC가 어느 디바이스가 현재 온라인이 되기 쉬운지를 볼 수 있도록 각각의 디바이스가 최종으로 발신한 때에 대한 급변동성 히스토리(volatile history)를 유지한다.

F. 추가의 실시예의 프로세스

도 14를 참조하면, 디바이스 구성을 위한 시퀀스 다이아그램이 도시되어 있다. EMS(395)는 디바이스를 위한 신속 접촉 파라미터를 설정하기 위해 이용되며(500), 요구된 파라미터를 CTData 데이터베이스(420)(도 13)에 전송한다. EMS는 또한 파라미터를 콘솔리데이션 서비스(400)에 전송한다(502).

도 15에는 디바이스 파라미터 업데이트를 위한 시퀀스 다이아그램이 도시되어 있다. 에이전트는 메인 서버로의 정규 발신을 행하며, 그 동안 통상의 메시지가 교환된다. 또한, 발신 동안에는, 메인 서버가 CTData 데이터베이스로부터 디바이스를 위한 신속 접촉 파라미터를 검색한다(522). 신속 접촉 파라미터는 디바이스 상에 설정되며(524), 이들이 설정된 후, 완료된 액션의 통지가 메인 서버(52)에 의해 EMS(395)를 통해 콘솔리데이션 서비스(400)에 전송된다(526). 이에 후속하여, 디바이스와 메인 서버 간에 교환되는 더 많은 표준 메시지가 있을 수 있다(528).

도 16에는 RCS의 시동에 대한 시퀀스 다이아그램이 도시되어 있다. 시동하기 위해, RCS는 신속 접촉 데이터베이스(405)로부터 임의의 미결 액션을 얻는다(540). RCS는 그리고나서 임의의 미결 액션을 로컬 액션 테이블 캐시(35)에 기록하고(542), 콘솔리데이션 서비스(400)에 등록한다(544).

도 17에는 새로운 파라미터 업데이트를 위한 또는 강제 발신을 위한 폴링에 대한 시퀀스 다이아그램이 도시되어 있다. 타이머의 만료 후(560), 콘솔리데이션 서비스(400)는 데이터베이스(405) 내의 액션 테이블로부터 새로운 액션을 획득하고(562), 그 후 새로운 액션에 대해 RCS에 통지한다(564).

도 18에는 미결 파라미터 업데이트 또는 강제 발신 지시의 부재 시의, RCS(30)에 대한 신속 에이전트 발신을 위한 시퀀스 다이아그램이 도시되어 있다. 먼저, 에이전트는 RCS에 대한 신속 발신(580)을 행한다. RCS는 디바이스의 최종 발신 시각을 콘솔리데이션 서비스에 전송하며(582), 콘솔리데이션 서비스가 최종 발신 시각을 인-메모리 데이터베이스(415) 내의 최종 발신 테이블에 전송한다(584). RCS는 디바이스(12)에 대해 미결 중일 수도 있는 임의의 액션을 로컬 데이터베이스 캐시(35)에서 찾는다(586). 아무 것도 없을 때에, RCS는 단순히 확인응답을 디바이스에게 역으로 전송한다.

도 19에는 미결 파라미터 업데이트 또는 강제 발신이 있을 때의 RCS(30)에 대한 신속 발신을 위한 시퀀스 다이아그램이 도시되어 있다. 먼저, 에이전트는 RCS에게 발신하며(600), RCS는 최종 발신 시각을 콘솔리데이션 서버에게 전송하며(602), 콘솔리데이션 서버가 최종 발신 시각을 데이터베이스 내의 최종 발신 테이블에 전송한다(604). RCS는 디바이스에 대한 임의의 미결 액션을 획득하며(606), 이 액션은 이 경우에는 설정될 새로운 파라미터이다. 새로운 파라미터는 에이전트에게 전송되며(608), 그리고나서, 액션이 완료된 후에는, 디바이스를 대기하는 액션의 리스트로부터 삭제된다(610). 완료된 액션은 그 후 콘솔리데이션 서버에서 완료됨으로서 설정되며(612), 콘솔리데이션 서버는 그 액션을 액션 테이블에 완료됨으로서 설정하고(614), 액션 테이블 히스토리에의 입력(entry)을 행한다(616).

G. 스케일링

신속 접촉 시스템(10)은 도 20에 나타낸 바와 같이 로드 밸런서(load balancer)(700)를 통해 네트워크(18)에 접속된 복수의 RCS를 포함할 수 있다. 콘솔리데이션 서버(400)의 최대 용량이 도달되면, 하나 이상의 추가의 콘솔리데이션 서버(702)가 추가될 수 있으며, 각각의 콘솔리데이션 서버가 소정 세트의 RCS(30)를 담당하고, 각각의 콘솔리데이션 서버가 이들에게 발신하도록 구성되는 디바이스(12)에 대한 데이터 및 액션을 저장하도록 구성된 대응하는 데이터베이스(705, 710)를 갖는다. 각각의 추가의 콘솔리데이션 서버 또는 콘솔리데이션 서버의 그룹에 대해, 발신할 대응하는 디바이스(12)에 대해 자기 자신의 공개 IP 어드레스를 갖는 또 다른 로드 밸런서가 추가될 수 있다. Apache Cassandra™, Microsoft Velocity™ 또는 Microsoft Server AppFabric™과 같은 고성능 분산 데이터 스토어가 이용될 수 있으며, 이로써 모든 콘솔리데이션 서버가 근본적으로 동일한 데이터에 대해 작업할 수 있다.

H. 산업상 이용가능성

신속 접촉 시스템은 데이터 삭제, 디바이스 동결 등과 같은 원격 디바이스에 대한 보안 방책을 호출하기 위해 디바이스의 관리자 또는 소유주에 대해 소요되는 시간을 감소시킬 수 있다. 더욱이, 보호된 디바이스와 모니터링 서버 간의 통신 채널의 이용가능성은 비용을 초래하지도 않고 연속적인 접속을 유지하기 위해 요구될 리소스 및 대역폭을 이용하지 않고서도 단속적이기는 하지만 빈번하게 유지된다.

I. 변형예

RCS(30)에 대한 상이한 발신 간격이 이용될 수 있다. 예컨대, RCS가 분당 100,000개의 발신을 핸들링할 수 있으면, 30분의 전조직에 미치는 발신 간격(system wide call interval of 30 minutes)은 3백만 개의 디바이스가 관리될 수 있도록 할 것이다. 이와 달리, 발신 간격이 5분으로 설정되면, 500,000만 개의 디바이스가 관리될 수 있다.

필드 또는 플래그를 판독하도록 요청되는 때에, 에이전트(14)는 요구되지 않은 필드 또는 플래그의 몇몇을 포함할 수도 있는 필드 또는 플래그의 세트가 아닌 관련 필드 또는 플래그만을 판독하도록 구성될 수 있다.

디바이스는 이들이 자신의 홈 네트워크에 접속되는지의 여부에 좌우되어 상이한 시간 간격으로 신속 발신을 행하도록 구성될 수 있다. 디바이스가 일반적으로 자신의 홈 네트워크에서는 더 안전한 것으로 간주됨에 따라, 예컨대 1시간과 같은 더 긴 신속 발신 간격이 수용될 수 있다. 디바이스가 사무실 또는 가정을 벗어날 때에, 덜 안전하게 되는 것으로 간주되며, 신속 발신 간격은 예컨대 5분으로 감소될 수 있다. 이 특징은 에이전트 내에서 또는 RCS 내에서 구현될 수 있다.

1차 RCS(primary RCS)가 장애가 발생하거나 또는 자신의 동작에서의 문제점을 나타내는 경우에는 백업 RCS가 채용될 수 있다.

몇몇 실시예에서, 개시된 아키텍처의 바탕이 되는 기본 원리는 기술적인 면에서 신속 접촉 서버를 사용하지 않고서도 실시될 수 있다. 그러므로, 예컨대, 몇몇 실시예에서, 모니터링 센터는 제1 서버 및 제2 서버를 포함하며, 각각의 서버는 상이한 각자의 프로토콜을 이용하여 전자 디바이스와 통신하며, 제2 서버(신속 접촉 서버이어도 되나, 반드시 그러할 필요는 없음)가 전자 디바이스와의 상대적으로 짧은 빈번한 통신을 핸들링하는데 더 적합하다. 제2 서버는 예컨대 전자 디바이스가 도난당한 것으로 보고된 때에 제1 서버에 접촉하도록 전자 디바이스에 지시할 수 있으며(제2 프로토콜을 이용하여), 전자 디바이스는 제1 서버와 접속하고(제1 프로토콜을 이용하여), 전술한 바와 같이 하나 이상의 보안 지시를 검색할 수 있다.

실현 가능한 곳에서, 하나의 서버에 의해 수행되는 것으로서 설명된 신속 접촉 시스템의 기능은 별도의 서버들 간에 나누어질 수 있으며, 복수의 서버 상에서 수행되는 것으로서 설명된 기능은 동일한 서버 상에서 합쳐질 수도 있다. 시스템에는 중간 서버(intermediate server)가 채용될 수도 있다. 데이터베이스는 또한 본 명세서에 도시된 것과는 상이한 아키텍처로 배열될 수도 있다.

디바이스(12)는 무작위로, 반무작위로, 또는 점차적으로 달라지는 시간 주기로 서버들 중의 하나 또는 둘 모두에 발신할 수 있다.

신속 발신이 수신되는 때에 신속 접촉 시스템(10)이 디바이스(12)에 확인응답을 전송하도록 구성되면, 아무런 액션이 취해지지 않을 때에, 에이전트(14)는 확인응답되지 않은 사전에 정해진 개수의 연속적인 신속 발신을 행한 후에 즉각적으로 메인 서버(52)에 발신하도록 구성될 수 있다.

신속 접촉 시스템(10)은 RCS에 의해 지시된 경우에 에이전트가 단지 메인 서버에 발신을 행하도록 구성될 수 있다. 디바이스에 대한 아웃스탠딩 액션이 없다면, 디바이스는 메인 서버에 발신할 필요가 없을 것이다.

RCS(30)에 대한 신속 발신은, 신속 발신의 부재(absence)가 하트비트(heartbeat)의 부재가 알려주는 것과 동일한 방식으로 어떠한 문제점을 나타내줄 필요는 없고 또는 하트비트로는 어떠한 정보가 운반되지만 신속 발신에서는 디바이스(12)의 상태에 관한 정보가 운반되지 않기 때문에, 하트비트와는 상이하다. 신속 발신은 또한 RCS(30)로부터의 응답이 필수적이지 않은 반면 핑(ping)은 응답을 요구하기 때문에 핑과는 상이하다. 신속 발신은 반드시 응답을 요구하지 않고 거리를 두고 접촉을 행하는 것을 나타내는 "포크(poke)"에 더 가깝다.

에이전트는 예컨대 접속이 모바일 브로드밴드를 통해 이루어졌는지의 여부와 같은 접속이 계량되기 쉬운지의 여부에 좌우되어 상이한 레이트로 RCS를 접촉하도록 구성될 수 있다.

흐름도에서의 단계는 예전된 것과는 다른 순서로 수행될 수 있거나, 또는 분리되어 도시된 곳에서는 합쳐질 수도 있다. 본 발명의 범위에서 벗어나지 않고서도, 이들 단계들은 생략되거나 또는 다른 단계가 추가될 수도 있으며, 상이한 흐름도로부터의 단계들이 서로 교환될 수도 있다. "에이전트"에 의해 수행되고 있는 것으로서 본 명세서에서 설명되는 태스크는 에이전트의 프로그램 코드의 실행을 통해서와 같이 에이전트의 제어 하에서 관련 디바이스에 의해 수행될 수 있다.

상이한 양, 상대적인 양, 크기, 시간 간격, 패킷 길이, 패킷의 수, 일련 번호 포맷, 및 기타 간단한 변경이 상정된다.

이상의 설명은 본 명세서에 개시되고 청구된 발명의 대상을 실행하는 현재 생각할 수 있는 최상의 모드에 대한 것이다. 이상의 설명은 발명의 대상의 일반적인 원리를 예시할 목적으로 이루어진 것이며 한정의 의미로 받아들여서는 안된다. 본 발명의 기저를 이루는 원리에 대한 이해로부터 해당 기술분야의 당업자에게 명백할 것인 바와 같이, 본 발명에 대해서는 개시된 내용의 범위를 벗어나지 않는 다양한 실시에 있어서의 활용성을 발견할 수 있다.

Claims (31)

1. 전자 디바이스를 모니터링하는 모니터링 시스템에 있어서,
   제1 프로토콜에 따라 전자 디바이스와 인터넷을 통해 통신하도록 구성되며, 상기 전자 디바이스 상에 저장된 데이터를 보호하는 보안 명령(security instruction)을 포함한, 분실되거나 도난당한 것으로서 보고된 전자 디바이스에 보안 명령을 송신하도록 구성되는 제1 서버; 및
   상기 제1 서버가 상기 전자 디바이스와 통신하는 것보다 큰 주파수로 제2 프로토콜에 따라 상기 전자 디바이스와 인터넷을 통해 통신하도록 구성되며, 분실되거나 도난당한 것으로서 보고된 전자 디바이스에게 상기 제1 서버에 접촉하도록 지시하여 상기 전자 디바이스가 상기 제1 서버로부터 보안 명령을 검색할 수 있게 하도록 구성된 제2 서버를 포함하며,
   상기 제2 프로토콜은 상기 제1 프로토콜을 이용하는 통신을 운반하는 패킷보다 작은 바이트(byte) 사이즈를 갖는 패킷을 이용하여 수행되는 통신을 위한 것이며,
   상기 제2 서버는 상기 전자 디바이스와 통신하기 위해 비-세션-특정 쓰레드의 풀(pool of non-session-specific thread)을 이용하며, 상기 제1 서버는 상기 전자 디바이스와의 특정 통신 세션에 전용되는 쓰레드를 이용하여 상기 전자 디바이스와 통신하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
2. 제1항에 있어서,
   상기 제2 프로토콜을 이용하는 통신은 상기 전자 디바이스 중 하나의 전자 디바이스로부터 상기 제2 서버에 전송된 하나의 패킷을 포함하고,
   상기 하나의 패킷은 상기 하나의 전자 디바이스의 식별(identification)을 포함하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
3. 제2항에 있어서,
   상기 하나의 패킷을 수신하는 것에 응답하여, 상기 제2 서버는 상기 식별 및 상기 식별에 연관된 플래그에 기초하여 상기 하나의 전자 디바이스와의 세션을 구축하여야 하는지를 판정하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
4. 제3항에 있어서,
   상기 제2 서버가 상기 세션을 구축하지 않아야 하는 것으로 판정하면, 상기 제2 서버는,
   상기 하나의 전자 디바이스에 응답하지 않거나,
   상기 하나의 전자 디바이스에게 확인응답(acknowledgment)을 전송하거나,
   상기 하나의 전자 디바이스에게 접속해제 명령을 전송하거나, 또는
   상기 하나의 전자 디바이스로부터 접속해제하고,
   상기 제2 서버가 상기 세션을 구축하여야 하는 것으로 판정하면, 상기 제2 서버는
   상기 하나의 전자 디바이스가 상기 세션을 오픈하도록 요청하는 메시지를 상기 하나의 전자 디바이스에게 전송하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
5. 제2항에 있어서,
   상기 하나의 패킷은 상기 식별 이외에는 상기 하나의 전자 디바이스에 관한 정보를 포함하지 않는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
6. 제2항에 있어서,
   상기 패킷은 2×10² 바이트 미만의 길이인,
   전자 디바이스를 모니터링하는 모니터링 시스템.
7. 제1항에 있어서,
   상기 제2 프로토콜을 이용하는 추가의 통신이 5개까지의 패킷을 갖는 제1 세션을 통해 발생하고,
   상기 제1 프로토콜을 이용하는 통신은 통신되는 바이트의 수의 면에서 상기 제1 세션보다 적어도 1 오더(order)의 크기가 더 큰 제2 세션을 통해 발생하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
8. 제1항에 있어서,
   상기 전자 디바이스가 각각 상기 제1 프로토콜과 상기 제2 프로토콜을 이용하여 상기 제1 서버 및 상기 제2 서버와 통신하도록 하기 위해 상기 전자 디바이스 상에 설치되도록 구성되는 에이전트를 더 포함하는,
   전자 디바이스를 모니터링하는 모니터링 시스템.
9. 전자 디바이스를 모니터링하는 방법에 있어서,
   전자 디바이스가 대기 보안 명령(an awaiting security instruction)을 갖는다는 통지를 제1 서버에서 수신하는 단계;
   상기 전자 디바이스가 상기 제1 서버와 접촉하여야 한다는 통지를 제2 서버에서 수신하는 단계;
   상기 전자 디바이스의 식별을 포함한 상기 전자 디바이스로부터의 하나의 패킷을 상기 제2 서버에서 인터넷을 통해 수신하는 단계;
   상기 식별이 상기 제1 서버에 접촉하도록 상기 전자 디바이스에 대해 플래그된다는 것을 상기 제2 서버에서 확인(confirm)하는 단계;
   상기 제2 서버가 상기 전자 디바이스에게 상기 제1 서버에 접촉하도록 지시하는 동안에 인터넷을 거쳐 상기 제2 서버와 상기 전자 디바이스 사이에 제1 세션을 구축하는 단계; 및
   상기 제1 서버가 상기 전자 디바이스에게 보안 명령을 통신하는 동안에 인터넷을 거쳐 상기 제1 서버와 상기 전자 디바이스 사이에 제2 세션을 구축하는 단계;를 포함하고,
   상기 제2 서버와의 세션은 상기 제1 서버와의 세션에서의 패킷보다 작은 바이트 사이즈를 갖는 패킷을 이용하여 수행되는,
   전자 디바이스를 모니터링하는 방법.
10. 제9항에 있어서,
    상기 제2 세션은 통신되는 바이트의 수의 면에서 상기 제1 세션보다 크기가 1-4 오더 더 큰,
    전자 디바이스를 모니터링하는 방법.
11. 제9항에 있어서,
    상기 제2 서버는 상기 전자 디바이스와 통신하기 위해 쓰레드의 풀을 이용하며, 상기 제1 서버는 특정 세션에 전용되는 쓰레드를 이용하여 상기 전자 디바이스와 통신하는,
    전자 디바이스를 모니터링하는 방법.
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제

Images