KR20130092937A - 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법 - Google Patents

Abstract

본 발명은 푸시 서버 클라우드 및 이를 이용한 통신 서비스를 제공하는 방법에 관한 발명이다.
본 발명의 일 실시예는 푸시 서버를 클라우드 방식으로 계층적 혹은 유기적으로 연동한다.
본 명세서의 일 실시예에 의한 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법은, 모바일 단말에서 구동하는 푸시 클라이언트 (Push Client)가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하는 단계, 및 상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하는 단계를 포함하며, 상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하는 것을 특징으로 한다.

Description

푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법{APPARATUS FOR PUSH SERVER CLOUD AND COMMUNICATION SERVICE OF USING PUSH SERVER CLOUD}

스마트폰의 보급에 따라 트래픽이 급증 하고 있으며 다양한 앱(Application, APP)의 수행으로 인하여, 통신망에 가중되는 부하가 증가하고 있다. 이러한 망 부하를 줄이기 위한 서버의 구성 및 통신 서비스를 제시한다.

스마트폰 또는 아이폰 등과 같이 어플리케이션이 다양하게 실행되는 장치의 보급에 따라 트래픽(Traffic)이 급증 하고 있으며 푸시(Push)형 앱(SNS, 메일 등)의 증가로 망부하가 심각해져 가고 있다. 특히 안드로이드(Android) OS 앱이 과도한 앱시그널링 발생시키고 있다. 과다한 앱시그널링을 살펴보면, 특정한 앱이 시간당 50~300회의 시그널링을 발생시키고 있다. 이에 따라 3%미만 과다 시그널링앱이 10~20%의 망부하 유발하고 있으며, 일부 무선망은 이러한 과도한 앱 시그널링 트래픽에 의해 기능이 마비되기도 하였다.

본 명세서에서는 이러한 개별적으로 운용되는 각 통신사, 조직 및 OS 벤더들의 푸시 서버(push server)를 유기적으로 연동하도록 함으로써 앱이 유발하는 트래픽 부하 문제들을 해결하고, 통신사에게 탄력적인 서버 운용을 가능하도록 하고, 개별 서버의 운용과 비교하여 새로운 차원의 향상된 서비스 안정성을 제공하고자 한다.

본 발명의 일 실시예는 푸시 서버를 클라우드 방식으로 계층적 혹은 유기적으로 연동한다.

본 발명의 일 실시예에 의한 푸시 서버 클라우드는 MNO, GSMA, OS 벤더들이 운영하는 푸시 서버들의 계층적 구조를 제공한다.

본 발명의 일 실시예에 의한 푸시 서버 클라우드는 MNO(Mobile Network Operator)가 관리하는 푸시 서버를 프라이머리 푸시 서버로 하며, 이에 대한 백업 푸시 서버로 GSMA(GSM Association) 푸시 서버를 제공하며, 또한 GSMA 푸시 서버에 대한 백업 푸시 서버로 OS 벤더 푸시 서버로 구현한다. 본 명세서의 일 실시예에 의한 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법은, 모바일 단말에서 구동하는 푸시 클라이언트 (Push Client)가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하는 단계, 및 상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하는 단계를 포함하며, 상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하는 것을 특징으로 한다.

본 명세서의 다른 실시예에 의한 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법은, 푸시 서버(Push Server) 및 백업 푸시 서버(Backup Push Server)로 구성된 푸시 서비스 시스템에 있어서, 상기 푸시 서비스 시스템이 모바일 단말에서 구동하는 푸시 클라이언트(Push Client)의 식별 정보를 수신하는 단계, 및 상기 푸시 클라이언트에 상기 백업 푸시 서버 또는 상기 푸시 서버가 푸시 데이터를 송신하는 단계를 포함하며,상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 백업 푸시 서버가 상기 푸시 클라이언트에게 상기 푸시 데이터를 송신하는 것을 특징으로 한다.

본 명세서의 또다른 실시예에 의한 푸시 서버 클라우드를 이용하는 모바일 단말은, 푸시 서비스를 이용함에 있어서, 푸시 서비스를 이용하여 어플리케이션을 수정 또는 변경하거나 데이터를 추가하는 어플리케이션 제어부, 상기 모바일 단말에 설치된 어플리케이션의 푸시 서비스를 제어하는 푸시 클라이언트(Push Client), 상기 푸시 클라이언가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하도록 제어하며, 상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하도록 제어하는 송수신부를 포함하며, 상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하는 것을 특징으로 한다.

본 명세서의 또다른 실시예에 의한 푸시 서버 클라우드를 구성하는 푸시 서버는, 푸시 서비스 시스템을 구성함에 있어서, 푸시 서비스에 이용할 푸시 데이터를 저장하는 저장부, 모바일 단말에서 구동하는 푸시 클라이언트(Push Client)의 식별 정보를 상기 푸시 클라이언트 또는 상기 푸시 서비스 시스템을 구성하는 제 2의 서버로부터 수신하며 상기 푸시 클라이언트에 푸시 데이터를 송신하는 송수신부, 및 상기 푸시 서비스를 이용할 푸시 클라이언트를 검증하는 클라이언트 검증부를 포함하며, 상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 서비스 시스템을 구성하는 백업 푸시 서버가 상기 푸시 클라이언트에게 상기 푸시 데이터를 송신하는 것을 특징으로 한다.

본 발명의 푸시 서버 클라우드 또는 푸시 서버 네트워크를 구현할 경우, 이전에 개별적으로 운용되는 각 통신사, 조직 및 OS 벤더들의 푸시 서버(push server)를 유기적으로 연동하도록 함으로써 앱이 유발하는 트래픽 부하 문제들을 해결하고, 통신사에게 탄력적인 서버 운용을 가능하도록 한다.

도 1은 개별적인 푸시 서버를 이용하는 서비스 구성을 보여주는 도면이다.
도 2는 개별적인 푸시 서버를 사용하는 구성을 보여주는 도면이다.
도 3은 본 명세서의 일 실시예에 의한 푸시 서버 클라우드의 구성을 보여주는 도면이다.
도 4는 본 명세서의 일 실시예에 의한 푸시 서버 클라우드 또는 푸시 서버 네트워크의 구성을 보여주는 도면이다.
도 5는 본 명세서의 일 실시예에 의한 푸시 서버들을 3계층으로 구성한 도면이다.
도 6은 본 명세서의 일 실시예에 의한 시그널링을 보여주는 도면이다.
도 7은 본 명세서의 다른 실시예에 의한 시그널링을 보여주는 도면이다.
도 8은 본 명세서의 또다른 실시예에 의한 시그널링을 보여주는 도면이다.
도 9는 본 명세서의 또다른 실시예에 의한 시그널링을 보여주는 도면이다.
도 10은 본 명세서의 일 실시예에 의한 도면이다.
도 11은 하나의 푸시 서버로 구성된 경우를 보여주는 도면이다.
도 12는 본 명세서의 일 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.
도 13은 본 명세서의 다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.
도 14는 본 명세서의 또다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.
도 15는 본 명세서의 또다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.
도 16은 본 발명의 일 실시예에 의한 백업 푸시 서버를 보여주는 도면이다.
도 17은 본 발명의 다른 실시예에 의한 백업 푸시 서버를 보여주는 도면이다.
도 18은 본 발명의 일 실시예에 의한 푸시 클라이언트와 푸시 서비스 시스템에서 이루어지는 프로세스를 보여주는 도면이다.
도 19는 본 명세서의 일 실시예에 의한 모바일 단말의 구성을 보여주는 도면이다.
도 20은 본 명세서의 일 실시예에 의한 푸시 서버의 구성을 보여주는 도면이다.

이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.

또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.

본 명세서에서는 통신 서비스에서의 푸시 서버를 클라우드로 구성하는 방안 및 이를 통한 통신 서비스, 서버 장치 등을 중심으로 설명한다. 그러나, 본 명세서에서 설명하고 있는 발명은 좁은 의미의 통신 서비스에 국한되는 것이 아니며, 데이터의 송수신을 가능하게 하는 광의의 통신 서비스에 적용 가능하다. 본 명세서에서의 앱(APP) 또는 어플리케이션(Application)은 통신 단말에 설치되는 프로그램 또는 소프트웨어를 통칭하는 것이며, 특정한 회사 혹은 특정한 통신 방식에 한정되지 않는다.

앞서 살펴본 바와 같이, 푸시형 앱의 증가로 인해 망에 대한 부하는 증가하고 있으며, 이에 따라 개별적인 푸시 서버(push server)를 구축하여 문제를 완화하는 방법이 있다.

그러나 개별적인 푸시 서버를 구축하는 것에는 다음과 같은 문제점을 가지고 있다.

각 통신사별로 각기 다른 방법을 사용하므로 각 통신사별로 앱 개발 방법이 달라져야 하고 이에 따라 앱 개발시에 개발자에게 푸시 서버의 사용을 강제하기 힘들다. 또한, 각 통신사별로 각기 다른 신뢰성, 안정성과 응답시간 등 QoS(Quality of Service)를 제공하므로, 개발자의 신뢰를 받기 힘들며, 스마트폰에서 실행되는 앱의 안정성에도 문제가 있을 수 있다.

도 1은 개별적인 푸시 서버를 이용하는 서비스 구성을 보여주는 도면이다.

기존의 푸시형 앱들(110)은 지속적으로 앱 서버(App Server)(190)에 새로운 데이터가 있는지를 확인하기 위한 신호들(130, 140), 예를 들어 인 킵-얼라이브 메시지(Keep-Alive message) 또는 리트라이 메시지(Retry message)를 보낸다. 이러한 트래픽을 경감시키기 위해 푸시 서버(100)가 개발되었으며, 각 통신사 및 OS 벤더(Operating System Vendor)은 도 2와 같이 독자적으로 운영할 수 있다.

도 2는 개별적인 푸시 서버를 사용하는 구성을 보여주는 도면이다. 세 대의 푸시 서버들(210, 220, 230)은 독자적인 서비스 서버(211, 221, 231)과 동작하고 있다.

본 발명에서는 도 1, 2의 구성과 달리 각 업체에서 운용되는 푸시 서버를 연동하여 푸시 서버 클라우드(Push Server Cloud)를 구축한다. 애플리케이션 관점에서는 푸시 서버 클라우드 서비스를 네트워크 API를 호출하는 방식(network API call)으로 구현하면 모든 처리는 실제로는 어떤 서버에 의해 실행되는지, 혹은 어떤 서버가 장애가 생기더라도 관계없이 앱의 입장에서는 동일한 서비스를 이용가능 하게 된다.

도 3은 본 명세서의 일 실시예에 의한 푸시 서버 클라우드의 구성을 보여주는 도면이다. 푸시 서버 클라우드 또는 푸시 서버 네트워크(Push Server network)(300)에 앱서버(App Server)(310)가 시그널링을 전달하면, 푸시 서버 클라우드 또는 푸시 서버 네트워크(300)는 푸시 알림(Push notification)(305)를 앱(어플리케이션)(330)으로 전달한다.

도 3과 같은 구성의 이러한 서비스 이용을 위해, 해당 통신 사업자는 푸시 서버의 주소들(primary, backup and OS vendor push server addresses)을 핸드폰의 통신사업자 데이터(data) 영역에 저장하고, 개발자들이 앱에서 통신사업자 또는 다른 푸시 서버에 푸시 서비스(push service)를 요청하는 것을 가능하도록 해주는 API 함수(API function)를 제공한다.

이를 이용하여, 앱 개발자는 간단한 네트워크 API 함수(network API function) 호출만으로 안정적인 푸시 서비스의 이용이 가능하며, 개발하는 앱의 특성에 따라 인액티브 타이머(inactive timer), 킵얼라이브 간격(keep alive interval) 및 푸시 알림 메시지의 간격(push notification message interval) 등을 결정 할 수 있다. 인액티브 타이머(Inactive timer)는 단말과 앱 서버간의 논리적인 통신 연결을 끊기 위한 시간을 의미한다. 킵얼라이브 간격(keep alive interval)은 킵얼라이브 메시지를 받기 위한 시간 간격을 결정한다. 최소 푸시 알림 메시지의 간격(The minimum push notification message interval)은 해당 앱이 푸시 서버로부터 푸시 알림 메시지를 받기 위한 최소 시간을 의미한다. 즉, 앱 서버에서 푸시 서버로 푸시 알림을 보낸다고 해서 즉시 업데이트 하는 것이 아니라 지정된 푸시 알림 메시지의 간격(push notification message interval)마다 푸시 알림이 전송된다.

개발자가 앱 내에서 이렇게 네트워크 API 함수(network API function)를 호출하게 되면, 해당 함수는 휴대폰의 운영 정보(Operator information)에서 프라이머리 푸시 서버(primary push server) 주소를 가져와서 등록 요청 메시지(registration request message)를 인증을 위한 AAA 서버(Authorization, Authentication and Accounting server)를 경유하여 해당 프라이머리 푸시 서버(primary push server)에 전송한다. 이 메시지를 받은 푸시 서버는 해당 앱에 대한 푸시 서버 엔트리(push service entry)를 만들어 푸시 서버 리스트(push server list)에 추가하여 관리하고, 해당 요청 메시지(request message)에 포함된 킵 얼라이브 간격(Keep Alive interval) 정보를 백업 푸시 서버(backup push server)에 전달한다. 만약 추후에 프라이머리 푸시 서버(primary push server)가 동작이 불가능 하게 되는 경우, 해당 앱은 백업 푸시 서버(backup push server)로부터의 킵 얼라이브 메시지를 받아 새로운 푸시 서버에 푸시 서비스를 등록하거나 해당 백업 푸시 서버(backup push server)에 푸시 서비스를 등록하게 된다.

프라이머리 푸시 서버는 해당 통신 사업자가 운영하는 푸시 서버일 수도 있지만, GSMA(Global System for Mobile communication Association)와 같은 통신사업자들의 연합체 또는 구글(Google)과 같은 OS 벤더일 수도 있다. 프라이머리 푸시 서버가 어떤 것이 될지는 해당 통신사업자가 지정 가능하다. 만약 프라이머리 푸시 서버가 해당 통신사업자가 운영하는 푸시 서버라고 해도 해당 푸시 서버가 고장나거나 로드가 집중되어 더 이상 푸시 서비스를 제공할 수 없는 경우, 해당 푸시 서버로의 푸시 서비스 요청(push service request)는 백업 푸시 서버로 전달 될 수 있다. 백업 푸시 서버 또한 고장나거나 로드가 집중되어 더 이상 푸시 서비스를 제공할 수 없는 경우, 해당 푸시 서버로의 푸시 서비스 요청은 상위 백업 푸시 서버로 전달 될 수 있다.

도 4는 본 명세서의 일 실시예에 의한 푸시 서버 클라우드 또는 푸시 서버 네트워크의 구성을 보여주는 도면이다.

푸시 서버(Push server)는 GGSN을 통해 IP기반 모바일 네트워크(IP-based mobile network)(450)와 연결된 인터넷 망에 구성 가능하다. 이 때 UMTS 네트워크와 푸시 서버를 연결하는 GGSN(Gateway GPRS Supporting Node)은 Ga 와 AAA 인터페이스를 통해 연결되므로 만약 푸시 서비스를 제공하는 푸시 서버의 운영주체가 푸시 서비스에 대해 요금을 받는다고 해도 요금 정산도 가능하다.

예를 들어, 스마트폰에서 동작하는 앱에서 해당 통신사업자의 푸시 서버(431)로 푸시 서비스 등록 요청 메시지(push service registration request message)를 보내면, 해당 통신사업자의 푸시 서버(431)에서 푸시 서비스를 제공하게 된다. 이때 해당 모바일 네트워크(450)과 해당 푸시 서버(431)를 연결하는 GGSN이 해당 푸시 서버의 고장 또는 오버로드(overload) 상태를 파악하기 위해 해당 등록 요청 메시지(registration request message)를 지정된 해당 푸시 서버(431)에 보내고, 만약 일정 시간 내에 ACK 응답이 없으면, 해당 푸시 서버(431)를 고장으로 판단한다. 만약 BUSY 메시지를 응답으로 받으면, 해당 푸시 서버(431)를 오버로드로 판단한다. 해당 푸시 서버(431)가 고장 또는 오버로드인 경우, 해당 GGSN은 해당 푸시 서버로의 푸시 서비스 요청(push service request)를 백업 푸시 서버(backup push server)(432) 전달한다. 만약 마찬가지로 GGSN에서 백업 푸시 서버(432) 또한 고장나거나 로드가 집중되어 더 이상 푸시 서버를 제공할 수 없다고 판단하는 경우, 해당 푸시 서버로의 푸시 서비스 요청은 상위 백업 푸시 서버인 OS 벤더 푸시 서버(OS vendor push server)(410)로 전달 될 수 있다.

이때 만약 해당 통신 사업자가 푸시 서버(push server)를 구축하지 않고 상위의 백업 푸시서버(backup push server)의 서비스를 이용하는 경우에는, 위의 타임아웃(time out)에 의한 지연(delay)을 없애기 위하여 가상 푸시 서버(virtual push server)를 구축하여 앱(app)으로부터의 푸시 서비스 요청(push service request)이 오는 경우 바로 이 요청을 상위 백업 푸시 서버(backup push server) 의 GGSN (gateway) 에 전달(forwarding)하거나 또는 해당 가상 푸시 서버(virtual push server) 앞단의 GGSN 에 BUSY 또는 네거티브 메시지(Negative message)를 보내 앱(app)으로부터의 푸시 서비스 요청(push service request)을 상위 백업 푸시서버(backup push server) 의 GGSN (gateway) 에 전달(forwarding)하도록 할 수 있다.

푸시 서비스를 받는 중에 해당 푸시 서버에 문제가 생기는 경우에도 서비스를 안정적으로 제공하기 위해, 본 명세서에서는 다음의 2가지 방법이 사용 가능하다.

첫 번째 방법으로, 해당 앱에서 지정된 킵 얼라이브 시간 내에 해당 푸시 서버에서 푸시 알림(push notification)이 오지 않는 경우, 스스로 해당 푸시 서버에 푸시 알림 서비스 등록 요청(push notification service registration request)를 다시 보내어 해당 푸시 서버가 제대로 동작하는지 확인하고, 제대로 동작하지 않는 경우, 백업 푸시 서버(backup push server)에 푸시 알림 서비스 등록 요청(push notification service registration request)를 보내어 서비스를 이용할 수 있다. 이 방법은 앱마다 각각 푸시 서버의 동작 상태를 모니터링하므로, 관련 시그널링 트래픽(signaling traffic)을 증가시키는 단점이 있고, 앱이 지속적으로 상태를 모니터링해야 하므로, 단말기의 로드가 증가하고, 배터리 사용시간이 짧아지는 단점이 있으나, 구현이 비교적 간편한 장점이 있다.

두 번째 방법은 앱에서 푸시 알림 서비스 등록 요청(push notification service registration request)를 보낼 때 이를 받은 프라이머리 푸시 서버(primary push server)에서 해당 푸시 서버(primary push server)의 백업 푸시 서버(backup push server)에 이 값을 등록하고, 해당 백업 푸시 서버(backup push server)가 등록된 킵 얼라이브 간격(keep alive interval) 값들 중 최소의 값에 해당하는 주기로 푸시 서버(primary push server)의 동작을 확인하여 푸시 서버(primary push server)가 문제가 있다고 판단되는 경우, 킵 얼라이브 메시지(keep alive message)를 해당 앱에 보내 백업 푸시 서버(backup push server)에서 푸시 알림 서비스(push notification service)를 받도록 한다. 두 번째 방법을 사용하는 경우, 앱마다 각각 푸시 서버의 동작 상태를 모니터링 하는 대신, 백업 푸시 서버(backup push server)에서만 푸시 서버의 동작 상태를 모니터링 하므로, 관련 시그널링 트래픽을 감소시킬 수 있는 장점이 있다.

도 5는 본 명세서의 일 실시예에 의한 푸시 서버들을 3계층으로 구성한 도면이다.

도 5의 실시예에서는 개념적으로, 푸시 서버들은 계층적으로 다음과 같이 3 계층으로 구성되어 운영된다. 일반적으로, 푸시 서비스는 통신사업자들이 운영하는 해당 지역에 구축된 푸시 서버들(MNO Push Server)(541, 542, 543, 551, 552, 553)에 의해 제공되며, 통신사업자들이 운영하는 푸시 서버들은 GSMA와 같은 통신사업자들이 구성한 단체에 의해 운영되는 전세계에 걸쳐 구축된 백업 푸시 서버(backup push servers)(521, 522)에 의해 백업된다. 그리고, 이러한 백업 푸시 서버는 다시 구글과 같은 OS 벤더들에 의해 운영되는 백업 푸시 서버(510)에 의해 백업된다.

그러나, 본 명세서의 실시예를 적용함에 있어서 통신사업자들이 통신사업자 자체의 푸시 서버를 운용하지 않고, 앱들이 기본적으로 GSMA의 푸시 서버(521, 522)를 이용하도록 할 수도 있고, 앱들이 통신사업자정보의 푸시 서버들을 이용하지 않고, 바로 OS 벤더의 푸시 서버(510)를 이용하는 것도 가능하다. 따라서 도 5의 계층 구조는 일 실시예가 되며, 푸시 서버를 1계층으로, 혹은 2, 3, 4, 5 이상의 계층으로 구현되도록 할 수도 있다. 물론 MNO 푸시 서버들도 자체적으로 계층화를 시켜서 그 내부에 푸시 서버를 가지도록 구현할 수 있다.

도 5와 같은 푸시 서버 네트워크 구조(push server network architecture)는 다음과 같은 장점을 갖는다.

1) 네트워크 부하문제 때문에 통신 사업자들의 입장에서는 시급히 푸시 서버가 필요한 시간적 요구사항을 만족시킬 수 있다.

2) 통신사업자들은 각자의 상황에 따라 독자적인 푸시 서버를 운용하거나 또는 독자적인 푸시 서버없이, 필요한 경우에만, GSMA 또는 OS 벤더의 푸시 서버를 이용 가능하다.

3) 서비스 제공을 위한 서버들이 표준화 되어 위와 같이 구축되면, 서버의 고장이나 지역적인 자연재해에도 서비스가 끊김없이(seamless) 제공 가능하므로, 서비스의 신뢰성이 높아진다.

4) 각 사업자들이 서버 실패에 대비하기 위한 자체적인 서버 이중화 대신 전세계적인 백업 서버 네트워크(backup server network) 구축으로 비용 절감이 가능하다.

5) 개발자들의 입장에서도 통신사업자의 푸시 서버이든, OS 벤더의 푸시 서버이든 동일한 방법으로 푸시 알림 서비스(push notification service) 이용이 가능하게 되어, 개발이 쉬워지며, 푸시 서버의 안정성이 높아져 앱에 의해 제공되는 서비스의 신뢰성이 높아진다.

6) 개발자들이 지금까지와는 달리 푸시 알림 서비스(push notification service)와 관련한 파라메터(parameter)들을 네트워크 API를 통해 직접 설정 가능하므로, 보다 앱에 최적화된 푸시 알림 서비스(push notification service) 이용이 가능하게 되어, 앱의 실행환경이 최적화된다. 그러나 이러한 파라메터들은 네트워크 로드나 통신사업자의 정책에 따라 사전에 합의된 기준에 따라 변경될 수 있다.

도 6은 본 명세서의 일 실시예에 의한 시그널링을 보여주는 도면이다.

앞서 살펴본 푸시 서버 네트워크 구조를 이용하는 서비스 제공을 위한 구성 요소 들 간의 시그널링은 다음과 같다. 스마트폰에서 동작하는 앱(610)에서 해당 통신사업자의 프라이머리 푸시 서버(primary push server)(630)로 푸시 알림 서비스 등록 요청 메시지(push notification service registration request message)를 보낸다(S671, S672). 해당 통신사업자의 푸시 서버(630)는 현재 부하상태를 체크하고(S673), 현재 부하가 여유가 있을 경우는, 해당 앱 서버(App Server)(640)에게 연결 요청(connection request)을 보내어 연결을 맺고(S674, S675), 킵 얼라이브 간격(keep alive interval)을 백업 푸시 서버(backup push server)(650)에 등록한 후(S676, S677), ACK 메시지를 보내어(S678, S679), 푸시 서비스를 제공하게 된다. 이때, 푸시 알림 서비스 등록 요청 메시지는 다음의 정보를 포함한다. 앞서 S673 단계는 로드를 체크해서 요청된 아이템을 서비스 리스트에 등록하는 것을 의미한다(Check load and register the requested item to the service list)

[푸시 알림 서비스 등록 요청 메시지에 포함되는 정보(push notification service registration request message)]

app_id, mobile_id, app_server_IP_address, InactiveTimer, KeepAliveInterval, PushInterval

이때 앱 서버(App Server)가 가짜가 아니라 실제 앱 서버(App Server)인지를 확인하기 위해 앱(App)은 푸시 서비스 요청(push service request) 시에 실행코드 내에 저장된 소정의 비밀키 (secret key)값을 보내고, 푸시 서버(push server)는 앱 서버(app server)로부터 해당 키 값을 받아 비교하는 절차를 거칠 수 있다.

도 6을 정리하면, 푸시 서비스를 제공하는 과정에서 프라이머리 푸시서버(630)에 부하가 있을 경우, 백업 푸시 서버(backup push server)(650)에서 푸시 서비스를 제공할 수 있다.

도 7은 본 명세서의 다른 실시예에 의한 시그널링을 보여주는 도면이다.

해당 모바일 네트워크와 해당 푸시 서버를 연결하는 GGSN(720)이 해당 푸시 서버(730)의 고장 또는 오버 로드상태를 파악하기 위해 해당 등록 요청 메시지(registration request message)를 지정된 해당 푸시 서버(730)에 보내고(S781, S782), 만약 일정 시간(time t) 내에 ACK 응답이 없으면, 해당 푸시 서버(730)를 고장으로 판단한다(S783). 만약 BUSY 메시지를 응답으로 받으면, 해당 푸시 서버(730)를 오버로드로 판단한다(S783). 해당 푸시 서버(730)가 고장 또는 오버로드인 경우, 해당 GGSN(720, 740)은 해당 푸시 서버(730)로의 푸시 서비스 요청(push service request)을 백업 푸시 서버(750)로 전달한다. 만약 마찬가지로 GGSN(720, 740)에서 백업 푸시 서버(750) 또한 고장나거나 로드가 집중되어 더 이상 푸시 서비스를 제공할 수 없다고 판단하는 경우, 해당 푸시 서버로의 푸시 서비스 요청은 상위 백업 푸시 서버인 OS 벤더 푸시 서버(770)으로 전달 될 수 있다. 도 7에는 3 개의 푸시 서버(730, 750, 770)이 있으며, 각 푸시 서버의 부하에 따라 푸시 서비스는 상위 계층으로 전달된다.

도 8은 본 명세서의 또다른 실시예에 의한 시그널링을 보여주는 도면이다.

푸시 알림 서비스(Push notification service)가 제공되는 중에 해당 백업 푸시 서버(backup push server)(850)는 등록된 킵 얼라이브 간격(keep alive interval)값들 중 최소의 값에 해당하는 주기로 프라이머리 푸시 서버(primary push server) (830)의 동작을 확인한다(S861, S862, S863). 상위 계층의 푸시 서버는 하위 계층의 푸시 서버의 동작을 확인하여, 상기 상위 계층의 푸시 서버보다 푸시 서비스의 요청을 먼저 받게 되는 하위 계층의 푸시 서버에서 푸시 서비스가 제대로 동작될 수 있는지를 체크할 수 있다.

도 9는 본 명세서의 또다른 실시예에 의한 시그널링을 보여주는 도면이다.

프라이머리 푸시 서버(primary push server)(930)가 문제가 있다고 판단되는 경우(S961, S962), 킵 얼라이브 메시지(keep alive message)를 해당 앱에 보낸다(S963). 해당 메시지를 받은 앱(910)은 앞서 설명한 바와 같이, 수신한 푸시 알림 서비스 등록 요청(push notification service registration request) 메시지를 다시 프라이머리 푸시 서버(primary push server)(930)에 보내어 서비스를 다시 이용하게 된다(S964, S965).

앱(app)에서 푸시 서버(push server)에서 비밀키(secret key)를 받아 앱 서버(app server)에 보내고, 다시 비밀키(secret key)를 앱 서버(app server)에 보내 앱 서버(app server)에서 푸시 서버(push server)와의 연결을 맺게 되는 경우 메시지 플로우(message flow)는 다음과 같이 수정된다. 이때 앱 서버(app server)가 가짜가 아니라 실제 앱 서버(app server)인지를 확인하기 위해 앱(App)은 푸시 서비스 요청(push service request) 시에 푸시 서버(push server)에서 받은 소정의 키 (secret key)값을 보내고, 푸시 서버(push server)는 앱 서버(app server)로부터 해당 키 값을 받아 비교하는 절차를 거칠 수 있다.

또는 통신사업자는 백업 푸시 서버(backup push server)의 비밀키(secret key)만을 발행하는 가상 서버(virtual server)만을 운영하고, 앱(app)에서 푸시 서비스(push service)를 요청하는 경우, 푸시 서버(push server)의 비밀키(secret key)를 발행하고 이를 백업 푸시 서버(backup push server)의 IP 주소(IP address)와 함께 app에 전송하여 해당 앱(app)이 바로 백업 푸시 서버(backup push server)의 푸시 서비스(push service)를 사용하도록 할 수 도 있다.

또한 통신사업자는 앱(app)에서 푸시 서비스(push service)를 요청하는 경우, 해당 요청을 바로 백업 푸시 서버로 전달하는 가상 서버(virtual server)만을 운영하여, 이후 비밀키(secret key)를 발행하는 단계부터 해당 앱(app)이 바로 백업 푸시 서버(backup push server)의 푸시 서비스(push service)를 사용하도록 할 수 도 있다.

도 9의 프로세스에서 프라이머리 푸시서버(930)에 오류가 발생한 후, 앱들이 푸시 서비스를 받을 수 있도록 연결을 재설정하는 과정에서, 백업 푸시 서버(950)이 새로운 프라이머리 푸시 서버의 정보를 앱에게 제공할 수 있다. 이는 프라이머리 푸시 서버(930)를 새로운 프라이머리 푸시 서버로 교체하는 경우 적용할 수 있다.

도 10은 본 명세서의 일 실시예에 의한 도면이다.

도 10에서는 가상 서버(virtual server)에서 요청(request)을 다음 단으로 포워딩(forwarding)하는 대신 regID+push server address를 발행하여 바로 백업 푸시 서버(backup push server)의 서비스를 이용가능 하도록 한다. 도 10에서는 앱(1010)이 할당받은 백업 푸시 서버(1050)의 주소로 새로이 접속하되 이러한 접속의 보안성을 유지하기 위하여 앱(1010)이 보안 통신을 수행하여 백업 푸시 서버(1050)로 접속을 수행할 수 있도록 한다.

또한 앱(app)(1010)과 앱 서버(app server)(1040)와의 보안통신을 위한 PKI (Public Key Infrastructure) 구성을 위해 푸시 서비스 요청(push service request) 시에 푸시 서버(push server)에서 인코딩(encoding)과 디코딩(decoding)을 위한 키 페어(key pair)를 보낼 수도 있다.

즉, 도 10에서 앱(App)(1010)에 비밀키(secret key)를 보낼 때 그리고 앱 서버(app server)(1040)에게 ack를 보낼 때 인코딩(encoding)과 디코딩(decoding)을 위한 키 페어(key pair)를 보낼 수도 있다.

참고로, PKI(Public Key Infrastructure)에 대해 간략히 살펴보면 다음과 같다.

이는 인터넷 사용자가 보유한 암호를 이용해 거래자 신원 확인하는 방식으로, 암호화와 복호화 키로 구성된 공개키(Public Key)를 이용해 송, 수신 데이터를 암호화하고 디지털 인증서를 통해 사용자를 인증하는 시스템이다.

암호화 알고리즘 RSA(비대칭키 암호화), 데이터 B, 키값 C 입력받아 암호화된 데이터 B_C만들어낼 수 있다. 예를 들어, 다음과 같이 진행된다.

RSA(B,C)=B_C

공개키 C_pub, 개인키 C_pri 유일하게 존재하며, 인증기관에서 관리한다.

RSA(B, C_pub) = B_C_pub, RSA(B, C_pri) = B_C_pri 이면

RSA(B_C_pub, C_pri) = RSA(B_C_pri, C_pub) = B 인 성질을 가진다.

개인키로 암호화한 것은 공개키로 풀리고, 공개키로 암호화한 것은 개인키로 풀리게 된다.

공개키 C_pub 알림은 다음과 같다.

송신자--(C_pri로 암호화)-->수신자(C_pub로 풀림: 송신자가 보냈음을 확인)

송신자--(C_pub로 암호화)-->수신자(C_pri로 풀림: 수신자(나)에게 보낸 것이 맞는지 확인)

데이터 암호화하는 방법은 다음과 같다.

비밀키는 송, 수신자 양측에서 똑같은 비밀키를 공유한다.

공개키는 암호화와 복호화 키가 다르기 때문에 데이터를 암호화하고 이를 다시 풀 수 있는 열쇠가 달라 거의 완벽한 데이터 보안이 가능하고 정보유출의 가능성이 적은 시스템이다.

이하, 본 발명을 구현하기 위한 세부 실시예를 살펴보고자 한다.

도 11은 하나의 푸시 서버로 구성된 경우를 보여주는 도면이다.

도 11에서 사용 가능한 옵션은 다음과 같다.

1110은 본 명세서의 일 실시예에 의한, 하나의 푸시 서버 동작을 보여주는 도면이다. 통상의 푸시 서버 동작을 보여준다. 어플리케이션(APP)(1111)이 푸시 클라이언트(push client)(1112)를 통하여 사용자 계정 정보(User Account)를 푸시 서버(1115)에게 제공하면, 푸시 서버(1115)는 등록 식별 정보(Reg ID)를 어플리케이션(1111)에게 제공한다. 어플리케이션(1111)은 수신한 등록 식별 정보(Reg ID)와 사용자 계정 정보(User Account)를 앱 서버(1118)에게 제공하면, 앱 서버(1118)는 등록 식별 정보(Reg ID)와 푸시 서비스로 제공할 데이터를 푸시 서버(1115)에게 제공하고, 푸시 서버(1115)는 상기 데이터를 해당하는 푸시 클라이언트(1112)에게 제공한다.

한편, 이 과정에서 표준화할 수 있는 인터페이스로는, 1120과 같이, 앱(1121)과 푸시 클라이언트(1122)간의 인터페이스(In Between App-Push Client), 푸시 클라이언트(1122)와 푸시 서버(1125)간의 인터페이스(In Between Push Client-Push Server), 그리고, 푸시 서버(1125)와 앱 서버(1128) 간의 인터페이스(In Between Push Server - App Server)가 존재할 수 있다. 또한, 푸시 서버 구조에 따라 푸시 클라이언트의 인터페이스가 필요할 수 있다.

푸시 서버 표준화(Push server standardization)에 있어서, 표준화 할것인지 말 것인지(Standardize or not), 만약 표준화를 한다면 어떻게 할 것인지(If standardize, how to do that?), 푸시 서버 간의 인터오퍼레이션을 위한 구현 옵션은 무엇인지?(Implementation options for interoperation of push servers), 이 경우, 중앙 관리 서버(Central Management Server)와 백업 푸시 서버(Backup Push Server)를 고려할 수 있다.

중앙 관리 서버(Central Management Server)의 역할은 다음과 같다.

해당하는 푸시 서버의 IP 주소에 대한 정보를 제공하여, 각각의 앱들이 해당하는 푸시 서버에 의해 푸시 서비스를 받을 수 있도록 한다(Provides information about the IP address of the corresponding push server so that each app can use the push service provided by the corresponding push server.). 그리고 앱과 앱 서버 인증 서비스를 제공한다(Provides app and app server authentication service)

중앙 관리 서버(Central Management Server)의 장점은 다음과 같다.

심플하며 간단한 구조를 가능하게 한다(Enables more simple and straightforward architecture.) 또한, 앱 서버 인증을 위한 PKI 없이 앱을 가장 쉽게 개발할 수 있도록 한다(Enables easier app development without PKI(Public Key Infrastructure) for app server authentication). 또한 MNO가 하나의 공통된 푸시 클라이언트를 이용할 수 있도록 한다(Enables MNOs to use one single common push client.)

도 12는 본 명세서의 일 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.

앱 개발자들은 그들의 앱과 앱 서버를 중앙 관리 서버에 미리 등록해야 한다(App developers should register theirs App and App Server to the Central Management Server in advance.) 보다 상세히 살펴보면 다음과 같다.

도 12의 주요 개체는 중앙 관리 서버(Central Management Server, 1280), 앱 서버(App Server, 1290), 그리고 MNO A의 푸시서버(MNO A Push server, 1230), MNO B의 푸시 서버(MNO B Push Server, 1240)과 공통의 푸시 클라이언트(Common push client, 1210)이 존재한다. 이들 간의 정보 교환 과정을 살펴보면 다음과 같다.

1. 푸시 클라이언트(1210)에서 중앙 관리 서버(1280)로 "푸시 서비스 요청(Push Service Request)" 메시지를 송신한다.

2. 중앙 관리 서버(1280)는 푸시 클라이언트(1210)에게 "푸시 서버 IP 주소(Push Serve IP Address)"를 제공한다.

3. 푸시 클라이언트(1210)는 MNO A의 푸시서버(1230)에게 "사용자 계정 정보와 앱 식별 정보(User Account + App ID)"를 제공한다.

4. MNO A의 푸시서버(1230)는 푸시 클라이언트(1210)에게 "등록 식별 정보(Reg ID)"를 제공한다.

5. 푸시 클라이언트(1210)는 앱 서버(App Server, 1290)에게 "사용자 계정 정보와 등록 식별 정보(User Account + Reg ID)"를 제공한다.

6. 앱 서버(App Server, 1290)는 MNO A의 푸시서버(1230)에게 "등록 식별 정보, 인증 정보, 데이터(Reg ID + Auth ID + Data)"를 제공한다. 상기 데이터는 푸시 서비스로 제공할 데이터이다.

B_4. 한편 앱 서버(App Server, 1290)는 MNO B의 푸시서버(1240)에게도 " 등록 식별 정보, 인증 정보, 데이터(Reg ID + Auth ID + Data)"를 제공한다.

B_5. MNO B의 푸시서버(1240)는 중앙 관리 서버(1280)에게 인증 정보(Auth ID)를 제공한다.

B_6. 중앙 관리 서버(1280)는 MNO B의 푸시서버(1240)에게 인증 정보를 확인한다.

7. MNO A의 푸시서버(1230)는 중앙 관리 서버(1280)에게 "앱 식별 정보, 인증 정보(App ID+ Auth ID)를 제공한다.

8. 중앙 관리 서버(1280)는 MNO A의 푸시서버(1230)에게 제공받은 정보를 확인(Confirm)한다.

9. MNO A의 푸시서버(1230)는 푸시 클라이언트(1210)에게 데이터를 제공한다.

도 13은 본 명세서의 다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.

도 13에서는 푸시 서버 1에 대한 대안적 접근을 보여준다(An alternative approach for routing to the push server 1).

앱 개발자들은 반드시 그들의 앱과 앱서버를 하나 이상의 MNO에 등록하며, 모든 푸시 서버는 해당하는 MNO의 인증 서버를 인증을 위해 요청한다(App developers should register their App and App Server to one or more MNOs. Every push server should ask the corresponding MNO’s authentication server for authentication.). 모든 MNO는 자신의 푸시 클라이언트를 개발한다(Every MNO should develop its own push client.)

도 13에서 MNO A에서 동작하는 푸시 클라이언트(Push Client for MNO A, 1311)과 MNO B에서 동작하는 푸시 클라이언트(Push Client for MNO B, 1312)는 각각 MNO A의 푸시 서버(MNO A Push server, 1330), MNO B의 푸시 서버(MNO B Push server, 1340)과 푸시 서비스를 이용한다.

1_A, 1_B. 각각의 푸시 클라이언트(1311 1312)는 각각의 푸시 서버(1330, 1340)에게 "사용자 계정 정보(User Account)"를 제공한다.

2_A, 2_B. 각각의 푸시 서버(1330, 1340)는 각각의 푸시 클라이언트(1311 1312)에게 식별 정보(Reg ID)를 제공한다.

3_A, 3_B. 각각의 푸시 클라이언트(1311 1312)는 계정 정보와 등록 식별 정보(User Account+ RegID)를 앱 서버(1390)에게 제공한다.

4_A, 4_B. 앱 서버(1390)는 각각의 푸시 서버(1330, 1340)에게 등록 식별 정보와 푸시 서비스로 제공할 데이터(Reg ID + Data)를 제공한다.

5_A, 5_B. 각각의 푸시 서버(1330, 1340)는 각각의 푸시 클라이언트(1311 1312)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

도 14는 본 명세서의 또다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.

앱 서버 인증에 대한 대안적 접근(1)이다(An alternative approach for app server authentication 1). 모든 개발자는 반드시 그들의 앱과 앱서버를 하나 이상의 MNO에 등록하며, 모든 푸시 서버는 해당하는 MNO의 인증 서버를 인증을 위해 요청한다(App developers should register their App and App Server to one or more MNOs. Every push server should ask the corresponding MNO’s authentication server for authentication.)

1. 푸시 클라이언트(1410)는 MNO A의 푸시서버(1430)에게 "사용자 계정 정보와 앱 식별 정보(User Account + App ID)"를 제공한다.

2. MNO A의 푸시서버(1430)는 푸시 클라이언트(1410)에게 "등록 식별 정보(Reg ID)"를 제공한다.

3. 푸시 클라이언트(1410)는 앱 서버(App Server, 1490)에게 "사용자 계정 정보와 등록 식별 정보(User Account + Reg ID)"를 제공한다.

4. 앱 서버(App Server, 1490)는 MNO A의 푸시서버(1430)에게 "등록 식별 정보, 인증 정보, 데이터(Reg ID + Auth ID + Data)"를 제공한다. 상기 데이터는 푸시 서비스로 제공할 데이터이다. 상기 인증 정보는 홈 푸시 서버에 대한 정보(Home Push Server Information)를 포함한다.

5. MNO A의 푸시서버(1430)는 MNO B의 푸시서버(1440)에게 앱 식별 정보와 인증 정보(App ID+Auth ID)를 제공한다.

6. MNO B의 푸시서버(1440)는 MNO A의 푸시서버(1430)에게 제공받은 정보를 확인(Confirm)한다.

7. MNO A의 푸시서버(1430)는 푸시 클라이언트(1410)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

도 15는 본 명세서의 또다른 실시예에 의한 중앙 관리 서버를 보여주는 도면이다.

앱 서버 인증 에 대한 대안적 접근(2)이다(An alternative approach for app server authentication 2).

앱을 위한 별도의 인증은 없다. 푸시 서버는 단지 요청에 따라 푸시 서비스를 제공한다. 앱 개발자는 앱 서버와 앱 간에 PKI를 이용한 보안 통신에 대해서만 책임을 진다. (No authentication for app servers. Push servers just provide push service whenever it is requested. App developers are responsible for the security communication between the App Server and the App using PKI.)

도 15에서 푸시 클라이언트(1410)와 앱 서버(1590) 간에는 PKI 통신을 수행한다.

1. 푸시 클라이언트(1410)는 MNO A의 푸시서버(1530)에게 "사용자 계정 정보 (User Account)"를 제공한다.

2. MNO A의 푸시서버(1530)는 푸시 클라이언트(1510)에게 "등록 식별 정보(Reg ID)"를 제공한다.

3. 푸시 클라이언트(1510)는 앱 서버(App Server, 1590)에게 "사용자 계정 정보와 등록 식별 정보(User Account + Reg ID)"를 제공한다.

4. 앱 서버(App Server, 1590)는 MNO A의 푸시서버(1530)에게 "등록 식별 정보, 데이터(Reg ID + Data)"를 제공한다. 상기 데이터는 푸시 서비스로 제공할 데이터이다.

5. MNO A의 푸시서버(1530)는 푸시 클라이언트(1510)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

백업 푸시 서버Backup Push Server)에 대해 살펴보면 다음과 같다.

백업 푸시 서버의 롤(role)은 MNO 푸시 서버를 이용할 수 없거나 존재하지 않는 경우 푸시 서비스를 제공한다(Provides push service when MNO push server is not available or does not exist)

백업 푸시 서버의 장점으로는 다음과 같다.

MNO가 지역적 재해 또는 거대한 트래픽으로 인한 네트워크 붕괴가 일어난 경우 푸시 서버를 이용할 수 있다(Enables MNOs to use push server in case of regional disasters or network collapse due to excessive traffic.)

MNO는 선택적으로 푸시 서비스를 제공할 수 있다(Enables MNOs to optionally provide push service.)

MNO가 그들만의 푸시 서버를 구동하지 않도록 옵션을 정할 수 있다Gives MNOs an option not to operate their own push server. )

MNO가 개발, 구현, 동작과 관련한 비용을 절감할 수 있다(Enables MNOs to save expenses for development, implementation and operation. )

도 16은 본 발명의 일 실시예에 의한 백업 푸시 서버를 보여주는 도면이다.

도 16에서는 MNO가 그들만의 푸시 서버를 구동하지 않도록 옵션을 제공한 경우(Provides options not to operate MNO’s own push server)를 보여준다.

도 16에서 MNO B의 푸시 서버(1630)는 가상 푸시 서버(Virtual Push Server)이다.

1_A, 1_B. 각각의 푸시 클라이언트(1611 1612)는 각각의 푸시 서버(1630, 1640)에게 "사용자 계정 정보(User Account)"를 제공한다.

2_A, 2_B. 각각의 푸시 서버(1630, 1640)는 각각의 푸시 클라이언트(1611 1612)에게 식별 정보(Reg ID)를 제공한다.

3_A, 3_B. 각각의 푸시 클라이언트(1611 1612)는 계정 정보와 등록 식별 정보(User Account+ RegID)를 앱 서버(1690)에게 제공한다.

4_A, 앱 서버(1690)는 MNO A 푸시 서버(1630)에게는 상기 등록 식별 정보와 푸시 서비스로 제공할 데이터(Reg ID + Data)를 제공한다.

4_B. 반면, MNO B의 푸시 서버(1630)는 가상 푸시 서버이므로, 앱 서버(1690)는 백업 푸시 서버(Backup Push Server, 1670)에게 상기 등록 식별 정보와 푸시 서비스로 제공할 데이터(Reg ID + Data)를 제공한다.

5_A, MNO A 푸시 서버(1630)는 푸시 클라이언트(1611)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

5_B. 백업 푸시 서버(1670)는 푸시 클라이언트(16123)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

도 16에서 MNO B는 푸시 서버를 운영하지 않거나, 혹은 푸시 서버의 동작에 문제가 발생하는 경우 등에 백업 푸시 서버를 통하여 MNO B의 푸시 클라이언트들이 푸시 서비스를 받을 수 있도록 한다.

도 17은 본 발명의 다른 실시예에 의한 백업 푸시 서버를 보여주는 도면이다.

MNO가 지역적 재해 또는 네트워크 붕괴가 일어난 경우 푸시 서버를 이용하는 경우(Provides push service in case of regional disaster or network collapse)를 보여준다.

도 17에서는 MNO가 제공하는 백업 서버로부터 푸시 서비스가 제공되지 않는 경우, 백업 푸시 서버를 통해 푸시 서비스를 받는 과정을 보여주는 도면이다.

M_1. 푸시 클라이언트(1710)는 MNO A의 푸시서버(1730)에게 "사용자 계정 정보 (User Account)"를 제공한다.

그러나, 상기 사용자 계정 정보를 제공하였음에도, MNO A의 푸시서버(1730)에 부하 혹은 에러 등으로 일정기간 이내에 등록 식별 정보를 푸시 클라이언트(1710)가 받지 못하는 경우(Time Out), 다음과 같이 프로세스가 진행된다.

1. 푸시 클라이언트(1710)는 백업 푸시서버(1770)에게 "사용자 계정 정보 (User Account)"를 제공한다.

2. 백업 푸시서버(1730)는 푸시 클라이언트(1710)에게 "등록 식별 정보(Reg ID)"를 제공한다.

3. 푸시 클라이언트(1710)는 앱 서버(App Server, 1790)에게 "사용자 계정 정보와 등록 식별 정보(User Account + Reg ID)"를 제공한다.

4. 앱 서버(App Server, 1790)는 백업 푸시서버(1730)에게 "등록 식별 정보, 데이터(Reg ID + Data)"를 제공한다. 상기 데이터는 푸시 서비스로 제공할 데이터이다.

5. 백업 푸시서버(1730)는 푸시 클라이언트(1710)에게 푸시 서비스로 제공할 데이터(Data)를 제공한다.

도 18은 본 발명의 일 실시예에 의한 푸시 클라이언트와 푸시 서비스 시스템에서 이루어지는 프로세스를 보여주는 도면이다. 도 18에서의 푸시 클라이언트는 앞서 살펴본 도 3 내지 도 17에서 살펴본 푸시 클라우드 서비스를 이용하는 푸시 클라이언트이며, 푸시 서비스 시스템은 푸시 서비스를 제공하는 푸시 클라우드를 구성하는 다수의 서버들로 이루어진 시스템을 의미한다. 푸시 클라이언트는 모바일 단말에서 구동되는 프로그램 혹은 모듈을 의미한다.

푸시 클라이언트(1810)는 푸시 서비스 시스템(1820)에게 푸시 클라이언트의 식별 정보를 송신한다(S1850). 이는 푸시 서비스를 받고자 하는 어플리케이션의 사용자 식별 정보가 될 수도 있고, 상기 푸시 클라이언트가 설치된 모바일 단말의 식별 정보가 될 수도 있다.

그리고 푸시 서비스 시스템(1820)에서는 푸시 서비스를 제공할 푸시 서버 또는 백업 푸시 서버를 결정한다(S1860). 이는 앞서 살펴본 바와 같이, MNO 푸시 서버, MNO의 상위 계층의 GSMA 백업 푸시 서버, OS 벤더에서의 백업 푸시 서버 등이 될 수 있으며, 또한, 도 16과 같이 가상 MNO 푸시 서버를 포함한다. 또한, 푸시 클라이언트와 관련된 앱 제공자가 운영하는 푸시 서버가 될 수도 있다. 또한, 푸시 서버를 결정함에 있어서, 푸시 클라우드 하의 계층적 구조하에서 상기 푸시 클라이언트가 탑재된 모바일 단말에 통신 서비스를 제공하는 MNO(Mobile Network Operator)에서 관리하는 MNO 푸시 서버에 장애가 발생한 경우에 상기 백업 푸시 서버가 동작하도록 구현할 수 있다.

상기 S1860의 결정 이후, 결정된 푸시 서버 또는 백업 푸시 서버에서 푸시 데이터(Push Data)를 송신한다(S1870).

보다 상세하게, 도 12, 13, 15의 실시예에서 살펴본 바와 같이, S1850 이후에 푸시 클라이언트는 상기 푸시 서버로부터 등록 식별 정보(Registration ID)를 수신하여 이를 앱 서버에 송신할 수 있다. 앱 서버 역시 푸시 서비스 시스템을 구성할 수 있다.

또한, 도 12에서 살펴본 바와 같이, S1850 이후에 상기 푸시 클라이언트는 중앙 관리 서버(Central Management Server)에 푸시 서비스를 요청하는 메시지를 송신하여 상기 푸시 서버의 IP 주소를 수신할 수 있다.

또한, 도 15에서 살펴본 바와 같이, 상기 앱 서버는 상기 푸시 서버에 상기 푸시 클라이언트에 대한 인증 정보(Authorization ID)를 제공할 수 있다.

본 명세서의 일 실시예에 의한 푸시 서버 또는 백업 푸시 서버는 푸시 클라이언트로부터 푸시 서비스의 요청이 있을 경우, 해당 푸시 클라이언트가 푸시 서비스를 받을 권한이 있는 푸시 클라이언트인지 검증하고, 푸시 클라이언트에게 푸시 데이터를 제공한다. 푸시 데이터란, 푸시 서비스를 통해, 푸시 클라이언트가 수신하고자 하는 데이터로, 예를 들어, 뉴스 어플리케이션인 경우, 새로운 기사가 될 수 있고, 업그레이드용 파일이거나, 혹은 알림 메시지 등이 될 수도 있다.

백업 푸시 서버가 푸시 클라이언트로부터 상기 푸시 클라이언트의 식별 정보(예를 들어 User Account와 App ID)를 수신할 수 있고, 이 값은 중앙 관리 서버 또는 앱 서버를 통해 인증 과정을 거친 후, 푸시 클라이언트에게 푸시 데이터를 제공할 수 있다. 이 과정에서, 푸시 클라이언트가 최초로 푸시 서비스를 요청했던 MNO가 관리하는 서버 외에도 푸시 클라우드 서버가 될 수도 있으며, 상기 MNO가 관리하는 서버는 단지 푸시 서비스 요청 메시지를 실제로 푸시 서비스를 제공하는 백업 푸시 서버로 전달하는 가상의 푸시 서버(도 16의 경우)가 될 수도 있다.

도 19는 본 명세서의 일 실시예에 의한 모바일 단말의 구성을 보여주는 도면이다. 도 19에서 설명하는 구성요소는 모바일 단말이 푸시 클라우드 서비스를 이용하기 위해 제공하는 구성 요소에 대해 상세히 설명하였으며, 그 외에, 본 발명의 구현과 직접적인 관련성이 없는 부분은 생략하였다. 모바일 단말(1900)은 푸시 서비스를 이용하며, 앞서 살펴본 바와 같이, 푸시 클라우드 서비스를 이용할 수 있다.

어플리케이션 제어부(1910)는 푸시 서비스를 이용하여 어플리케이션을 수정 또는 변경하거나 데이터를 추가한다. 어플리케이션 제어부(1910)는 어플리케이션 그 자체가 될 수도 있고, 상기 어플리케이션에 푸시 데이터를 결합하거나 업그레이드하기 위한 작업을 수행할 수 있다.

푸시 클라이언트(Push Client)(1920)는 상기 모바일 단말에 설치된 어플리케이션의 푸시 서비스를 제어한다. 푸시 서버 혹은 백업 푸시 서버의 접속 주소를 수신하거나, 푸시 서비스를 위해 필요한 식별 정보를 제공할 수 있다. 구현 방식에 따라, 어플리케이션 제어부(1910)와 푸시 클라이언트(1920)는 하나의 프로그램으로 구현될 수 있다.

송수신부(1930)는 모바일 네트워크 또는 무선 네트워크, 혹은 근거리 통신망 등을 이용하여 모바일 단말이 외부와 데이터를 송수신할 수 있도록 한다. 도 19에서는 보다 상세히, 상기 송수신부(1930)는 상기 푸시 클라이언가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하도록 제어하며, 상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하도록 제어한다.

또한, 상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트(1920)는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하게 된다. 푸시 클라이언트(1920)가 백업 푸시 서버 또는 푸시 클라우드 등을 통하여 푸시 서비스를 이용하는 방식은 앞서 설명하였으므로 생략한다.

도 20은 본 명세서의 일 실시예에 의한 푸시 서버의 구성을 보여주는 도면이다. 도 20에서 설명하는 구성요소는 푸시 클라우드 서비스를 제공하기 위해 필요한 구성 요소에 대해 상세히 설명하였으며, 그 외에, 본 발명의 구현과 직접적인 관련성이 없는 부분은 생략하였다. 푸시 서버(2000)는 MNO가 운영하는 푸시 서버가 될 수 있고, GSMA가 운영하는 백업 푸시 서버가 될 수 있으며, 또한 OS 벤더가 운영하는 백업 푸시 서버가 될 수도 있다. 또한, 앞서 살펴본 MNO가 운영하는 가상의 서버로부터 푸시 서비스를 요청 받아 푸시 서비스를 제공하는 백업 푸시 서버 또는 푸시 클라우드를 구성하는 다수의 푸시 서버들 중 하나일 수 있다.

푸시 서버의 구성요소로는 푸시 서비스에 이용할 푸시 데이터를 저장하는 저장부(2020)와 푸시 클라이언트(Push Client)의 식별 정보를 상기 푸시 클라이언트 또는 상기 푸시 서비스 시스템을 구성하는 제 2의 서버로부터 수신하며 상기 푸시 클라이언트에 푸시 데이터를 송신하는 송수신부(2030), 그리고, 상기 푸시 서비스를 이용할 푸시 클라이언트를 검증하는 클라이언트 검증부(2010)를 포함한다.

상기 제 2의 서버로부터 푸시 클라이언트의 식별정보를 수신하는 경우는 도 20의 푸시 서버가 백업 서버로 동작하거나, 앱서버 또는 중앙 관리 서버를 통하여 선택되어 푸시 서비스를 제공하는 경우를 포함한다. 또한, 푸시 클라이언트가 MNO가 운영하는 푸시 서버로부터 별도의 푸시 서비스를 받지 못할 경우, 내재적으로 설정되거나, 앱 서버 등을 통하여 수신한 백업 푸시 서버의 IP 주소를 이용하여 푸시 클라이언트가 직접 백업 푸시 서버에게 식별 정보를 송신할 수 있다.

또한, 푸시 서버(2000)가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 서비스 시스템을 구성하는 또다른 백업 푸시 서버가 상기 푸시 클라이언트에게 상기 푸시 데이터를 송신할 수 있다.

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시 예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시 예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (14)

1. 모바일 단말에서 구동하는 푸시 클라이언트(Push Client)가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하는 단계; 및
   상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하는 단계를 포함하며,
   상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하는 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
2. 제 1항에 있어서,
   상기 푸시 서버는 상기 푸시 클라이언트가 탑재된 모바일 단말에 통신 서비스를 제공하는 MNO(Mobile Network Operator)에서 관리하는 MNO 푸시 서버이며,
   상기 백업 푸시 서버는 상기 하나 이상의 MNO 푸시 서버에 대하여 백업 푸시 서비스를 제공하는 백업 서버인 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
3. 제 2항에 있어서,
   상기 백업 푸시 서버는 상기 푸시 클라이언트와 관련된 앱 제공자 또는 상기 푸시 클라이언트가 탑재된 모바일 단말의 운영 체계(Operating System) 제공자에서 운영하는 푸시 서버인 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
4. 제 1항에 있어서,
   상기 푸시 클라이언트의 식별 정보를 송신하는 단계 이후에
   상기 푸시 클라이언트는 상기 푸시 서버로부터 등록 식별 정보(Registration ID)를 수신하여 이를 앱 서버에 송신하는 단계를 더 포함하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
5. 제 4항에 있어서,
   상기 푸시 클라이언트의 식별 정보를 송신하는 단계 이전에
   상기 푸시 클라이언트는 중앙 관리 서버(Central Management Server)에 푸시 서비스를 요청하는 메시지를 송신하여 상기 푸시 서버의 IP 주소를 수신하는 단계를 더 포함하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
6. 제 4항에 있어서,
   상기 앱 서버는 상기 푸시 서버에 상기 푸시 클라이언트에 대한 인증 정보(Authorization ID)를 제공하는 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
7. 푸시 서버(Push Server) 및 백업 푸시 서버(Backup Push Server)로 구성된 푸시 서비스 시스템에 있어서,
   상기 푸시 서비스 시스템이 모바일 단말에서 구동하는 푸시 클라이언트(Push Client)의 식별 정보를 수신하는 단계; 및
   상기 푸시 클라이언트에 상기 백업 푸시 서버 또는 상기 푸시 서버가 푸시 데이터를 송신하는 단계를 포함하며,
   상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 백업 푸시 서버가 상기 푸시 클라이언트에게 상기 푸시 데이터를 송신하는 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
8. 제 7항에 있어서,
   상기 푸시 서버는 상기 푸시 클라이언트가 탑재된 모바일 단말에 통신 서비스를 제공하는 MNO(Mobile Network Operator)에서 관리하는 MNO 푸시 서버이며,
   상기 백업 푸시 서버는 상기 하나 이상의 MNO 푸시 서버에 대하여 백업 푸시 서비스를 제공하는 백업 서버인 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
9. 제 8항에 있어서,
   상기 백업 푸시 서버는 상기 푸시 클라이언트와 관련된 앱 제공자 또는 상기 푸시 클라이언트가 탑재된 모바일 단말의 운영 체계(Operating System) 제공자에서 운영하는 푸시 서버인 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
   
10. 제 7항에 있어서,
    상기 푸시 클라이언트의 식별 정보를 수신하는 단계 이후에
    상기 푸시 서비스 시스템은 상기 푸시 클라이언트에게 등록 식별 정보(Registration ID)를 송신하며,
    상기 푸시 클라이언트는 이를 앱 서버에 송신하는 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
    
11. 제 10항에 있어서,
    상기 푸시 클라이언트의 식별 정보를 수신하는 단계 이전에
    중앙 관리 서버(Central Management Server)가 상기 푸시 클라이언트로부터 푸시 서비스를 요청하는 메시지를 수신하여 상기 푸시 서버의 IP 주소를 상기 푸시 클라이언트에게 송신하는 단계를 더 포함하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
    
12. 제 10항에 있어서,
    상기 앱 서버는 상기 푸시 서버에 상기 푸시 클라이언트에 대한 인증 정보(Authorization ID)를 제공하는 것을 특징으로 하는, 푸시 서버 클라우드 및 이를 이용한 통신 서비스 제공 방법.
    
13. 푸시 서비스를 이용하는 모바일 단말에 있어서,
    푸시 서비스를 이용하여 어플리케이션을 수정 또는 변경하거나 데이터를 추가하는 어플리케이션 제어부;
    상기 모바일 단말에 설치된 어플리케이션의 푸시 서비스를 제어하는 푸시 클라이언트(Push Client);
    상기 푸시 클라이언가 푸시 서버(Push Server)가 포함된 푸시 서비스 시스템에 상기 푸시 클라이언트의 식별 정보를 송신하도록 제어하며, 상기 푸시 클라이언트는 백업 푸시 서버(Back Push Server) 또는 상기 푸시 서버로부터 푸시 데이터를 수신하도록 제어하는 송수신부를 포함하며,
    상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 클라이언트는 상기 백업 푸시 서버로부터 상기 푸시 데이터를 수신하는 것을 특징으로 하는, 푸시 서버 클라우드를 이용하는 모바일 단말.
    
14. 푸시 서비스 시스템을 구성하는 푸시 서버에 있어서,
    푸시 서비스에 이용할 푸시 데이터를 저장하는 저장부;
    모바일 단말에서 구동하는 푸시 클라이언트(Push Client)의 식별 정보를 상기 푸시 클라이언트 또는 상기 푸시 서비스 시스템을 구성하는 제 2의 서버로부터 수신하며 상기 푸시 클라이언트에 푸시 데이터를 송신하는 송수신부; 및
    상기 푸시 서비스를 이용할 푸시 클라이언트를 검증하는 클라이언트 검증부를 포함하며,
    상기 푸시 서버가 상기 푸시 데이터를 송신하지 못할 경우, 상기 푸시 서비스 시스템을 구성하는 백업 푸시 서버가 상기 푸시 클라이언트에게 상기 푸시 데이터를 송신하는 것을 특징으로 하는, 푸시 서버 클라우드를 구성하는 푸시 서버.
    
    
    
    
    

Images