KR101602186B1 - Apparatus for push server cloud and communication service of using push server cloud - Google Patents

Abstract

The present invention relates to a method of providing a push server cloud and a communication service using the push server cloud.
One embodiment of the present invention interlocks push servers in a hierarchical or organic way in a cloud manner.
According to an embodiment of the present invention, a push server cloud and a method of providing a communication service using the push server include a push client operating in a mobile terminal, a push server, Wherein the push client includes receiving push data from a back push server or the push server, and when the push server fails to transmit the push data, Is characterized in that the push data is received from the backup push server.

Description

TECHNICAL FIELD [0001] The present invention relates to a push server cloud and a communication service providing method using the push server cloud.

Traffic is increasing rapidly due to the spread of smartphones, and the load on the network is increasing due to the execution of various applications (APP, APP). We propose a server configuration and communication service to reduce the network load.

Traffic is rapidly increasing due to the spread of devices that are used for various applications such as a smart phone or an iPhone, and network load is becoming serious due to an increase in push-type applications (SNS, mail, etc.). In particular, Android OS apps are causing excessive app signaling. If you look at excessive app signaling, certain apps are generating 50 to 300 signaling times per hour. Thus, less than 3% excess signaling apps are causing 10 ~ 20% network load, and some wireless networks have been paralyzed by these excessive appsignaling traffic.

In this specification, it is possible to solve the traffic load problems caused by the app by organically linking the push servers of the individual operating companies, organizations and OS vendors, to enable flexible operation of the server, And to provide a new level of improved service stability compared to the operation of individual servers.

One embodiment of the present invention interlocks push servers in a hierarchical or organic way in a cloud manner.

The push server cloud according to an exemplary embodiment of the present invention provides a hierarchical structure of push servers operated by MNO, GSMA, and OS vendors.

The push server cloud according to an exemplary embodiment of the present invention uses a push server managed by a MNO (Mobile Network Operator) as a primary push server, a GSMA (GSM Association) push server as a backup push server for the push server, It is implemented as an OS vendor push server as a backup push server for push servers. According to an embodiment of the present invention, a push server cloud and a method of providing a communication service using the push server include a push client operating in a mobile terminal, a push server, Wherein the push client includes receiving push data from a back push server or the push server, and when the push server fails to transmit the push data, Is characterized in that the push data is received from the backup push server.

According to another aspect of the present invention, there is provided a push service system comprising a push server and a backup push server, the push service system comprising: Receiving a push client identification information of a push client running on the push server, and transmitting the push data to the push client by the backup push server or the push server, wherein the push server transmits the push data If not, the backup push server sends the push data to the push client.

According to another embodiment of the present invention, a mobile terminal using a push server cloud includes an application control unit for using the push service to modify or change an application using a push service or to add data, A push client for controlling a push service; a push client for sending identification information of the push client to a push service system including a push server, the push client being a push push server Wherein the push client receives the push data from the backup push server when the push server fails to transmit the push data, wherein the push client receives the push data from the push server, The.

According to another embodiment of the present invention, a push server constituting a push server cloud includes a storage unit for storing push data to be used for a push service, a push client for driving the mobile terminal, And a client verification unit for verifying the push client that uses the push service, and a client verification unit for receiving the identification information of the push client from the second server constituting the push client or the push service system and transmitting the push data to the push client, And when the push server fails to transmit the push data, a backup push server constituting the push service system transmits the push data to the push client.

When implementing the push server cloud or push server network of the present invention, it is possible to solve the traffic load problems caused by the application by organically linking the push server of each previously operated carrier, organization and OS vendors , Enabling flexible operation of the server.

1 is a diagram showing a service configuration using an individual push server.
2 is a diagram showing a configuration using an individual push server.
3 is a diagram illustrating a configuration of a push server cloud according to an embodiment of the present invention.
FIG. 4 is a diagram illustrating the configuration of a push server cloud or push server network according to an embodiment of the present invention.
FIG. 5 is a diagram illustrating push servers according to an embodiment of the present invention in three layers.
6 is a diagram illustrating signaling according to an embodiment of the present invention.
7 is a diagram illustrating signaling according to another embodiment of the present disclosure.
8 is a diagram illustrating signaling according to another embodiment of the present disclosure.
9 is a diagram illustrating signaling according to another embodiment of the present disclosure.
10 is a diagram according to an embodiment of the present invention.
11 is a diagram showing a case where the push server is composed of one push server.
12 is a diagram illustrating a central management server according to an embodiment of the present invention.
13 is a view showing a central management server according to another embodiment of the present invention.
14 is a view showing a central management server according to another embodiment of the present invention.
15 is a view showing a central management server according to another embodiment of the present invention.
16 is a diagram illustrating a backup push server according to an embodiment of the present invention.
17 is a diagram illustrating a backup push server according to another embodiment of the present invention.
18 is a diagram illustrating a process in a push client and a push service system according to an embodiment of the present invention.
19 is a diagram illustrating a configuration of a mobile terminal according to an embodiment of the present invention.
20 is a diagram illustrating a configuration of a push server according to an embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference numerals whenever possible, even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be "connected," "coupled," or "connected. &Quot;

In this specification, a method of configuring a push server in a communication service as a cloud, a communication service through the push server, and a server device will be described. However, the invention described in the present specification is not limited to a communication service in a narrow sense, and is applicable to a broad communication service enabling data transmission and reception. The application (APP) or application in this specification refers to a program or software installed in a communication terminal, and is not limited to a specific company or a specific communication method.

As we have seen, the load on the network is increasing due to the increase in push type apps, and there is a way to alleviate the problem by building a separate push server.

However, building individual push servers has the following problems.

Since each communication company uses different methods, it is difficult to force the developer to use the push server when developing an app. In addition, since each communication company provides QoS (Quality of Service) such as reliability, stability and response time, it is difficult to obtain the trust of the developer and the stability of the app running on the smartphone may be a problem.

1 is a diagram showing a service configuration using an individual push server.

Existing push-type apps 110 continue to receive signals 130 and 140 to confirm that there is new data in the app server 190, e.g., a keep-alive message ) Or a retry message. To reduce such traffic, a push server 100 has been developed, and each of the carriers and OS vendors can independently operate as shown in FIG.

2 is a diagram showing a configuration using an individual push server. The three push servers 210, 220, and 230 are operating with their own service servers 211, 221, and 231.

In the present invention, a Push Server Cloud is constructed by linking push servers operated by respective vendors, unlike the configurations shown in FIGS. From an application point of view, implementing a push server cloud service as a network API call means that all processing is actually executed by the server, or even if a server fails, Becomes available.

3 is a diagram illustrating a configuration of a push server cloud according to an embodiment of the present invention. The push server cloud or the push server network 300 transmits push notification 305 to the push server cloud 300 or the push server network 300 when the app server 310 transmits signaling to the push server cloud or the push server network 300. [ To the application (application) 330.

In order to use such a service as shown in FIG. 3, the communication service provider stores the addresses of the push server (primary, backup, and OS vendor push server addresses) in the data area of the carrier's mobile phone, And provides an API function that enables a service provider or another push server to request a push service.

Using this, an app developer can use a stable push service by simply calling a network API function. In addition, an inactive timer, a keep alive interval, And a push notification message interval of the push notification message. An inactive timer is a time for disconnecting a logical communication connection between a terminal and an application server. The keep alive interval determines the time interval for receiving the keepalive message. The minimum push notification message interval means the minimum time for the application to receive a push notification message from the push server. That is, the push notification is sent every push notification message interval of the designated push notification message rather than immediately updating the push notification from the app server to the push server.

When the developer calls the network API function in the application, the function fetches the primary push server address from the mobile operator's operating information and sends a registration request message message to the corresponding primary push server via an Authorization, Authentication and Accounting (AAA) server for authentication. The push server receiving this message creates a push service entry for the corresponding app and adds it to the push server list and manages it. When the push server receives the keep alive interval (Keep) included in the request message, Alive interval information to the backup push server. If the primary push server becomes unavailable in the future, the application receives the keepalive message from the backup push server and registers the push service with the new push server, The push service is registered to the server (backup push server).

The primary push server may be a push server operated by the carrier, but may be a carrier of a carrier such as Global System for Mobile Communications Association (GSMA) or an OS vendor such as Google. The primary push server can be specified by the carrier. If the primary push server is a push server operated by the carrier, if the push server fails or the load is concentrated and can no longer provide the push service, a push service request to the push server, May be forwarded to the backup push server. If the backup push server also fails or is heavily loaded and can no longer provide the push service, the push service request to that push server can be forwarded to the upstream backup push server.

FIG. 4 is a diagram illustrating the configuration of a push server cloud or push server network according to an embodiment of the present invention.

The push server is configurable in the Internet network connected to the IP-based mobile network 450 via the GGSN. In this case, the Gateway GPRS Supporting Node (GGSN), which connects the UMTS network and the push server, is connected through the AA and AA interface. Therefore, even if the push server providing the push service receives a charge for the push service, It is possible.

For example, when a push service registration request message is sent from a smart phone to a push server 431 of a corresponding communication provider, the push server 431 of the corresponding service provider provides a push service . At this time, the GGSN connecting the mobile network 450 and the corresponding push server 431 transmits a registration request message to the corresponding push server (i.e., a push server) to identify a failure or an overload state of the push server 431, and if the ACK response is not received within a predetermined time, the push server 431 is determined as a failure. If the BUSY message is received in response, the push server 431 is judged as an overload. If the push server 431 is malfunctioning or overloaded, the GGSN forwards a push service request to the push server to the backup push server 432. If the backup push server 432 in the GGSN likewise determines that the backup push server 432 also fails or is under load and can no longer provide the push server, the push service request to that push server is forwarded to the OS vendor push server vendor push server 410).

In this case, if the service provider uses the service of the backup push server without building a push server, in order to eliminate the delay caused by the above time out, When a push service request comes from an app (app) by constructing a virtual push server, this request is forwarded to the GGSN (gateway) of the backup push server ) Or sends a push service request from the app to the upper backup push server by sending a BUSY or a negative message to the GGSN in front of the corresponding virtual push server. To the GGSN (gateway) of the GGSN.

In order to reliably provide the service even when the push server experiences a problem while receiving the push service, the following two methods are available in this specification.

As a first method, if a push notification is not received from the corresponding push server within a predetermined keep-alive time, the push notification service registration request is sent back to the corresponding push server by itself, If the server is not functioning properly, the service can be used by sending a push notification service registration request to the backup push server. This method has the disadvantage of increasing the signaling traffic associated with each of the apps because it monitors the operation status of the push server for each app, and because the app continuously monitors the status, the load of the terminal increases, However, it is relatively easy to implement.

In the second method, when the application sends a push notification service registration request, the application receives a backup push server of the corresponding primary push server from a primary push server, The backup push server confirms the operation of the primary push server at a cycle corresponding to the minimum value of the keep alive interval values registered in the backup push server, (primary push server) has a problem, a keep alive message is sent to a corresponding application to receive a push notification service from a backup push server. In the second method, instead of monitoring the operation status of the push server for each application, the operation status of the push server is monitored only by the backup push server, thereby reducing the related signaling traffic .

FIG. 5 is a diagram illustrating push servers according to an embodiment of the present invention in three layers.

In the embodiment of FIG. 5, the push servers are hierarchically structured to operate in three layers as follows. In general, the push service is provided by push servers (MNO Push Servers) 541, 542, 543, 551, 552, and 553 installed in a corresponding region operated by communication carriers, and push servers operated by communication carriers Are backed up by backup push servers 521 and 522 built around the globe that are operated by organizations that are composed of carriers such as the GSMA. This backup push server is then backed up by the backup push server 510, which is again operated by OS vendors such as Google.

However, in applying the embodiment of the present invention, it is possible that the telecommunication carriers do not operate the push server of the telecommunication carrier itself but the apps basically use the GSMA push server 521, 522, It is also possible to use the push server 510 of the OS vendor directly without using push servers of the OS vendor. Therefore, the hierarchical structure of FIG. 5 is an embodiment, and the push server may be implemented as one layer, or two, three, four, five or more layers. Of course, MNO push servers can also be layered by themselves and implemented with a push server inside.

The push server network architecture shown in FIG. 5 has the following advantages.

1) Due to the network load problem, it is possible for the service providers to meet the time requirement that urgently needs the push server.

2) Operators can use their own push servers according to their own situation, or push servers of GSMA or OS vendors only when necessary, without proprietary push servers.

3) When the servers for service provision are standardized and constructed as described above, the service can be seamlessly provided even in the event of a server failure or a local natural disaster, thereby enhancing the reliability of the service.

4) It is possible to reduce costs by establishing a worldwide backup server network instead of the own server redundancy for each operator to prepare for server failure.

5) For developers, it is possible to use the push notification service in the same way as the push server of the communication carrier or the OS vendor, so that the development becomes easier, the stability of the push server becomes higher, The reliability of the provided service is enhanced.

6) It is possible for the developers to set the parameters related to the push notification service directly through the network API, so that it is possible to use the push notification service more optimized for the application, Your app's execution environment is optimized. However, these parameters can be changed according to the network load or carrier's policy and agreed upon in advance.

6 is a diagram illustrating signaling according to an embodiment of the present invention.

Signaling among the components for providing the service using the push server network structure as described above is as follows. The application 610 operating in the smartphone sends a push notification service registration request message to the primary push server 630 of the corresponding communication provider (S671, S672). The push server 630 of the corresponding communication company checks the current load state at step S673 and if there is a current load, the push server 630 sends a connection request to the corresponding app server 640, (S674, S675), registers the keep alive interval in the backup push server 650 (S676, S677), sends an ACK message (S678, S679), and provides the push service . At this time, the push notification service registration request message includes the following information. In step S673, the load is checked and the requested item is registered in the service list (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

At this time, in order to confirm whether the app server is not a fake but an actual app server, the app stores a predetermined secret key stored in the executable code at the time of push service request, Value, and the push server may receive the key value from the app server and compare the key value.

Referring to FIG. 6, if there is a load on the primary push server 630 in the process of providing the push service, the backup push server 650 can provide a push service.

7 is a diagram illustrating signaling according to another embodiment of the present disclosure.

The GGSN 720 connecting the mobile network and the corresponding push server sends a registration request message to the designated push server 730 in order to grasp the failure or overload state of the push server 730 (S781, S782). If there is no ACK response within a predetermined time (time t), it is determined that the corresponding push server 730 has failed (S783). If the BUSY message is received in response, the push server 730 is determined to be an overload (S783). The corresponding GGSN 720 and 740 delivers a push service request to the corresponding push server 730 to the backup push server 750 if the corresponding push server 730 fails or is overloaded. If the GGSN 720, 740 also determines that the backup push server 750 also fails or is under load and can no longer provide push services, the push service request to that push server is forwarded to the OS To the vendor push server 770. In FIG. 7, there are three push servers 730, 750, and 770, and the push service is delivered to the upper layer according to the load of each push server.

8 is a diagram illustrating signaling according to another embodiment of the present disclosure.

While the push notification service is being provided, the backup push server 850 may send a primary push server (primary) to the primary push server in a period corresponding to a minimum of the registered keep alive interval values push server 830 (S861, S862, S863). The push server of the upper layer confirms the operation of the push server of the lower layer and can check whether the push service can be properly operated in the push server of the lower layer which receives the push service request first than the push server of the upper layer have.

9 is a diagram illustrating signaling according to another embodiment of the present disclosure.

If the primary push server 930 determines that there is a problem (S961, S962), it sends a keep alive message to the corresponding application (S963). The application 910 receiving the message sends the received push notification service registration request message to the primary push server 930 again to use the service again (S964, S965).

In the app, a secret key is received from the push server and sent to the app server. The secret key is sent to the app server to send the app server ), The message flow is modified as follows when a connection with a push server is established. At this time, in order to check whether the app server is not a fake but an actual app server, the app stores a predetermined key received from a push server at a push service request secret key value, and the push server can receive the key value from the app server and compare the key value.

Alternatively, the communication service provider may operate only a virtual server that issues only a secret key of a backup push server, and when a push service is requested in an app, the application sends a secret key of the push server and transmits it to the app together with the IP address of the backup push server so that the app can be directly connected to the backup push server ) Push service may be used.

Further, when a service provider requests a push service from an app, the service provider operates only a virtual server that directly transmits the request to the backup push server, and then issues a secret key The application may allow the push service of the backup push server to be used immediately.

In the process of FIG. 9, after an error has occurred in the primary push server 930, in the process of resetting the connection so that the apps can receive the push service, the backup push server 950 sends the information of the new primary push server to the app . This can be applied when replacing the primary push server 930 with a new primary push server.

10 is a diagram according to an embodiment of the present invention.

In FIG. 10, the service of the backup push server is made available by issuing the regID + push server address instead of forwarding the request from the virtual server to the next step. 10, in order to maintain the security of the connection, the application 1010 performs secure communication and connects to the backup push server 1050 by newly connecting to the address of the backup push server 1050 allocated by the application 1010 To be performed.

Also, in order to configure a PKI (Public Key Infrastructure) for secure communication between an app (app) 1010 and an app server (1040), a push server a key pair for encoding and decoding may be sent.

That is, when transmitting a secret key to an app 1010 and sending an ack to an app server 1040 in FIG. 10, a key pair for encoding and decoding, (key pair).

For reference, PKI (Public Key Infrastructure) will be briefly described as follows.

This is a system that identifies a trader by using a password possessed by an Internet user, encrypts the transmitted and received data using a public key composed of encryption and decryption keys, and authenticates the user through a digital certificate.

Encryption algorithm RSA (asymmetric key encryption), data B, and key value C to generate encrypted data B_C. For example, proceed as follows.

RSA (B, C) = B_C

Public key C_pub, and private key C_pri, and is managed by the certification authority.

RSA (B, C_pub) = B_C_pub, and RSA (B, C_pri) = B_C_pri

RSA (B_C_pub, C_pri) = RSA (B_C_pri, C_pub) = B.

The private key is decrypted with the public key, and the public key is decrypted with the private key.

The public key C_pub notification is as follows.

Sender - (encrypted with C_pri) -> receiver (unpacked with C_pub: confirm sender sent)

Sender - (Encrypted with C_pub) -> Recipient (Unpacked with C_pri: Make sure it is sent to the recipient (B))

Here's how to encrypt your data:

The secret key shares the same secret key on both sides of the sender and receiver.

Since public keys have different encryption and decryption keys, they have the key to encrypt and re-encrypt the data, making it possible to secure almost complete data security and less information leakage.

Hereinafter, detailed embodiments for implementing the present invention will be described.

11 is a diagram showing a case where the push server is composed of one push server.

The options available in FIG. 11 are as follows.

1110 is a diagram illustrating one push server operation according to an embodiment of the present invention. It shows the normal push server operation. When the application (APP) 1111 provides the user account information to the push server 1115 through the push client 1112, the push server 1115 transmits the registration ID information (Reg ID) And provides it to the application 1111. When the application 1111 provides the received registration identification information (Reg ID) and user account information (User Account) to the application server 1118, the application server 1118 transmits the registration identification information (Reg ID) The push server 1115 provides the data to the push server 1115, and the push server 1115 provides the data to the corresponding push client 1112. [

The interface standardized in this process includes an interface between the application 1121 and the push client 1122 and an interface between the push client 1122 and the push server 1125, Interface between the push server 1125 and the application server 1128, and an interface between the push server 1125 and the application server 1128 (In Between Push Server and App Server). Also, depending on the push server architecture, a push client interface may be required.

For push server standardization, standardize or not, if standardize, how to do that, and implementation options for interoperation between push servers, In this case, a central management server and a backup push server may be considered.

The role of the Central Management Server is as follows.

Provide information about the IP address of the corresponding push server so that each application can receive the push service by the corresponding push server. push service provided by the corresponding push server. Provides app and app server authentication service (Provides app and app server authentication service)

The advantages of the Central Management Server are as follows.

Enables the simplest and simplest structure (Enables more simple and straightforward architecture.) It also makes it easiest to develop an app without a PKI for app server authentication (Enables easier app development without PKI ). It also allows MNOs to use a common push client (Enables MNOs to use a single common push client.)

12 is a diagram illustrating a central management server according to an embodiment of the present invention.

App developers should register their apps and app servers with the central management server in advance (App developers should register their apps and apps to the Central Management Server in advance.)

12 includes a central management server 1280, an app server 1290, and a push server MNO A Push server 1230, a push server MNO B Push Server 1240, and a common push client 1210 exist. The process of exchanging information among them is as follows.

1. Push client 1210 sends a "Push Service Request" message to central management server 1280.

2. The central management server 1280 provides the push client 1210 with a "push server IP address ".

3. Push client 1210 provides "user account information and app identification information (User Account + App ID)" to push server 1230 of MNO A.

4. Push server 1230 of MNO A provides "registration identification information (Reg ID)" to push client 1210.

5. The push client 1210 provides "User account information and registration identification information (User Account + Reg ID)" to the app server (App Server)

6. The app server 1290 provides "registration ID information, authentication information, data (Reg ID + Auth ID + Data)" to the push server 1230 of the MNO A. The data is data to be provided to the push service.

B_4. On the other hand, the app server 1290 also provides "registration identification information, authentication information, data (Reg ID + Auth ID + Data)" to the push server 1240 of the MNO B.

B_5. The push server 1240 of MNO B provides authentication information (Auth ID) to the central management server 1280.

B_6. The central management server 1280 confirms the authentication information to the push server 1240 of the MNO B. [

7. Push server 1230 of MNO A provides "app identification information, authentication information (App ID + Auth ID)" to central management server 1280.

8. The central management server 1280 confirms the information provided to the push server 1230 of the MNO A.

9. Push server 1230 of MNO A provides data to push client 1210.

13 is a view showing a central management server according to another embodiment of the present invention.

Figure 13 shows an alternative approach to push server 1 (an alternative approach to routing server 1).

App developers must register their apps and app servers with one or more MNOs, and all push servers request authentication for their MNO's authentication server (App developers should register their App and App Server to one or more MNOs. Every push server should ask for the corresponding MNO's authentication server for authentication. Every MNO develops its push client (Every MNO should develop its own push client.)

13, a push client (MNO A) 1311 operating in the MNO A and a push client (MNO B) 1312 operating in the MNO B are respectively connected to a MNO A push server 1330 ), A push server (MNO B Push server, 1340) of the MNO B, and a push service.

1_A, 1_B. Each push client 1311 1312 provides "User Account Information" to each push server 1330,1340.

2_A, 2_B. Each push server 1330, 1340 provides identification information (Reg ID) to each push client 1311 1312.

3_A, 3_B. Each push client 1311 1312 provides account information and registration identification information (User Account + RegID) to the app server 1390.

4_A, 4_B. The app server 1390 provides registration ID information and data (Reg ID + Data) to be provided as a push service to each of the push servers 1330 and 1340.

5_A, 5_B. Each push server 1330, 1340 provides data (Data) to provide to each push client 1311 1312 as a push service.

14 is a view showing a central management server according to another embodiment of the present invention.

This is an alternative approach for app server authentication (1). All developers must register their apps and app servers with one or more MNOs, and all push servers will ask for authentication of their MNO's authentication server (App developers should register their App and App Server to one or more MNOs. Every push server should ask for the corresponding MNO's authentication server for authentication.)

1. Push client 1410 provides "user account information and app identification information (User Account + App ID)" to push server 1430 of MNO A.

2. The push server 1430 of the MNO A provides "registration identification information (Reg ID)" to the push client 1410.

3. The push client 1410 provides "user account information and registration identification information (User Account + Reg ID)" to the app server (App Server) 1490.

4. The app server 1490 provides "registration ID information, authentication information, data (Reg ID + Auth ID + Data)" to the push server 1430 of the MNO A. The data is data to be provided to the push service. The authentication information includes information about a home push server (Home Push Server Information).

5. Push server 1430 of MNO A provides app identification information and authentication information (App ID + Auth ID) to push server 1440 of MNO B. [

6. The push server 1440 of the MNO B confirms the information provided to the push server 1430 of the MNO A.

7. Push server 1430 of MNO A provides data (Data) to be provided to push client 1410 as a push service.

15 is a view showing a central management server according to another embodiment of the present invention.

An alternative approach to app server authentication is (2).

There is no separate authentication for the app. The push server provides a push service only upon request. The app developer is solely responsible for secure communication between the app server and the app using PKI. (No authentication for app servers.) Push servers provide a push service whenever it is requested.

In FIG. 15, PKI communication is performed between the push client 1410 and the application server 1590.

1. Push client 1410 provides "User Account" to push server 1530 of MNO A.

2. The push server 1530 of the MNO A provides the push client 1510 with "registration identification information (Reg ID) ".

3. Push client 1510 provides "User account information and registration identification information (User Account + Reg ID)" to App server 1590.

4. App server 1590 provides "registration ID information, data (Reg ID + Data)" to push server 1530 of MNO A. The data is data to be provided to the push service.

5. Push server 1530 of MNO A provides data (Data) to be provided to push client 1510 as a push service.

Backup Push Server) is as follows.

The backup push server role provides a push service when the MNO push server is unavailable or does not exist (Provide push service when MNO push server is not available or does not exist)

Advantages of the backup push server include:

MNOs can use a push server in the event of a local disaster or a network collapse due to massive traffic. (Enables MNOs to use push servers in regional disasters or network collapse due to excessive traffic.)

MNOs can optionally provide push services (Enables MNOs to provide provide push service.)

MNOs can set options so that they do not run their own push servers. )

MNOs can reduce development, implementation, and operational costs (Enables MNOs to save expenses for implementation and operation.)

16 is a diagram illustrating a backup push server according to an embodiment of the present invention.

Figure 16 shows the MNO's own push server when the MNO provides an option not to drive their own push server.

In FIG. 16, push server 1630 of MNO B is a virtual push server.

1_A, 1_B. Each push client 1611 1612 provides "User Account Information" to each push server 1630,1640.

2_A, 2_B. Each push server 1630, 1640 provides identification information (Reg ID) to each push client 1611, 1612.

3_A, 3_B. Each push client 1611 1612 provides account information and registration identification information (User Account + RegID) to the app server 1690.

4_A and the app server 1690 provide the registration identification information and data (Reg ID + Data) to be provided to the MNO A push server 1630 as a push service.

4_B. The push server 1630 of the MNO B is a virtual push server and the app server 1690 transmits the registration identification information and the data (Reg ID + Data) to be provided as a push service to the backup push server 1670, Lt; / RTI >

5_A, the MNO A push server 1630 provides the push client 1611 with data (Data) to be provided as a push service.

5_B. The backup push server 1670 provides the push client 16123 with data (Data) to provide as a push service.

In FIG. 16, the MNO B allows the push clients of the MNO B to receive the push service through the backup push server when the push server is not operated or a problem occurs in the operation of the push server.

17 is a diagram illustrating a backup push server according to another embodiment of the present invention.

If the MNO has a local disaster or a network collapse, it shows the push server in case of regional disaster or network collapse.

FIG. 17 is a diagram showing a process of receiving a push service through a backup push server when a push service is not provided from a backup server provided by the MNO.

M_1. Push client 1710 provides "User Account Information" to push server 1730 of MNO A.

However, if the push client 1710 does not receive the registration identification information within a predetermined period due to a load or an error in the push server 1730 of the MNO A (Time Out) even though the user account information has been provided, It proceeds.

1. Push client 1710 provides "User Account Information" to backup push server 1770. [

2. Backup push server 1730 provides "registration identification information (Reg ID)" to push client 1710.

3. The push client 1710 provides "user account information and registration identification information (User Account + Reg ID)" to the application server (App Server)

4. The app server 1790 provides "registration ID information, data (Reg ID + Data)" to the backup push server 1730. The data is data to be provided to the push service.

5. Backup push server 1730 provides push client 1710 with data (Data) to provide as a push service.

18 is a diagram illustrating a process in a push client and a push service system according to an embodiment of the present invention. The push client in FIG. 18 is a push client using the push cloud service shown in FIGS. 3 to 17, and the push service system is a system including a plurality of servers constituting a push cloud that provides a push service. A push client refers to a program or module that is run on a mobile terminal.

The push client 1810 transmits the identification information of the push client to the push service system 1820 (S1850). This may be user identification information of an application to receive a push service or identification information of a mobile terminal installed with the push client.

The push service system 1820 determines a push server or a backup push server to provide the push service (S1860). As described above, the MNO push server, the GSMA backup push server in the upper layer of the MNO, the backup push server in the OS vendor, and the like also include a virtual MNO push server as shown in FIG. It may also be a push server operated by an app provider associated with the push client. In addition, in determining the push server, when a failure occurs in an MNO push server managed by a mobile network operator (MNO) that provides a communication service to a mobile terminal equipped with the push client under a hierarchical structure under a push cloud, The server can be implemented to operate.

After the determination in S1860, push data is transmitted from the determined push server or backup push server (S1870).

More specifically, as shown in FIGS. 12, 13, and 15, the push client receives the registration ID from the push server after S1850 and transmits the registration ID to the app server. The app server can also configure the push service system.

Also, as shown in FIG. 12, after pushing the S1850, the push client may receive a push service request message to the Central Management Server to receive the push server IP address.

Also, as shown in FIG. 15, the app server may provide authentication information (Authorization ID) for the push client to the push server.

The push server or the backup push server according to an embodiment of the present invention verifies whether the push client is a push client authorized to receive the push service when a push service is requested from the push client and provides push data to the push client do. The push data may be a new article, a file for upgrade, a notification message, or the like when the push client receives data to be received by the push client, for example, a news application.

The backup push server can receive the identification information (e.g., User Account and App ID) of the push client from the push client, and this value is authenticated through the central management server or the app server, Data can be provided. In this process, the push client may be a push cloud server in addition to the server managed by the MNO that originally requested the push service, and the server managed by the MNO merely transmits the push service request message to the backup push server (In the case of FIG. 16).

19 is a diagram illustrating a configuration of a mobile terminal according to an embodiment of the present invention. The components described in FIG. 19 have been described in detail with respect to the components that the mobile terminal provides for using the push-cloud service, and other portions that are not directly related to the implementation of the present invention are omitted. The mobile terminal 1900 uses a push service, and as described above, can use a push cloud service.

The application control unit 1910 uses the push service to modify or change the application or add data. The application control unit 1910 may be an application itself or may perform an operation for combining or upgrading push data to the application.

A push client 1920 controls a push service of an application installed in the mobile terminal. It can receive the connection address of the push server or the backup push server, or provide the identification information necessary for the push service. According to the implementation method, the application control unit 1910 and the push client 1920 can be implemented as a single program.

The transmission / reception unit 1930 enables a mobile terminal to transmit and receive data to / from the outside using a mobile network, a wireless network, or a local area network. 19, the transmission / reception unit 1930 controls the push client to transmit the identification information of the push client to the push service system including the push server, and the push client is connected to the backup push server Push Server) or push data from the push server.

Further, when the push server fails to transmit the push data, the push client 1920 receives the push data from the backup push server. The manner in which the push client 1920 uses the push service through the backup push server, the push cloud, or the like has been described above and will be omitted.

20 is a diagram illustrating a configuration of a push server according to an embodiment of the present invention. The components described in FIG. 20 have been described in detail in order to provide a push-cloud service, and other components not directly related to the implementation of the present invention have been omitted. The push server 2000 may be a push server operated by the MNO, a backup push server operated by the GSMA, or a backup push server operated by an OS vendor. Also, it may be one of a backup push server that provides a push service from a virtual server operated by the MNO as described above, or a plurality of push servers that constitute a push cloud.

As a component of the push server, a storage unit 2020 for storing push data to be used for a push service and identification information of a push client are received from the push client or a second server constituting the push service system A transmission / reception unit 2030 for transmitting push data to the push client, and a client verification unit 2010 for verifying a push client to use the push service.

When receiving the identification information of the push client from the second server, the push server of FIG. 20 may be operated as a backup server, or may be selected through an app server or a central management server to provide a push service. If the push client does not receive a separate push service from the push server operated by the MNO, the push client may directly set it to the backup push server by using the IP address of the backup push server received through the app server or the like Identification information can be transmitted.

Further, when the push server 2000 fails to transmit the push data, another backup push server constituting the push service system may transmit the push data to the push client.

The foregoing description is merely illustrative of the technical idea of the present invention and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents thereof should be construed as falling within the scope of the present invention.

Claims (14)

Transmitting a push client identification information to a push service system including a push server, the push client operating in the mobile terminal;
The push client receiving registration ID from the push server and transmitting the registration ID to the app server; And
Wherein the push client comprises receiving push data from a back push server or the push server,
And if the push server fails to transmit the push data, the push client receives the push data from the backup push server, and the push server cloud and method of providing a communication service using the same.
The method according to claim 1,
The push server is an MNO push server managed by an MNO (Mobile Network Operator) that provides a communication service to a mobile terminal equipped with the push client,
Wherein the backup push server is a backup server that provides a backup push service to the one or more MNO push servers.
3. The method of claim 2,
Wherein the backup push server is a push server operated by an operating system provider of an application provider associated with the push client or a mobile terminal equipped with the push client, and a method of providing a communication service using the push server cloud .
delete The method according to claim 1,
Before the step of transmitting the identification information of the push client
Wherein the push client further comprises a step of transmitting a push service request message to the central management server to receive an IP address of the push server, and a method for providing a communication service using the push server cloud.
The method according to claim 1,
Wherein the application server provides authentication information (Authorization ID) to the push server to the push server, and a method of providing a communication service using the push server cloud.
A method of providing a push server cloud and a communication service using the push server in a push service system including a push server and a backup push server,
The push service system receiving identification information of a push client driven by a mobile terminal;
The push service system transmitting registration ID to the push client; And
Wherein the backup push server or the push server transmits push data to the push client,
If the push server fails to send the push data, the backup push server sends the push data to the push client,
Wherein the push client transmits the registration identification information to the app server.
8. The method of claim 7,
The push server is an MNO push server managed by an MNO (Mobile Network Operator) that provides a communication service to a mobile terminal equipped with the push client,
Wherein the backup push server is a backup server that provides a backup push service to the one or more MNO push servers.
9. The method of claim 8,
Wherein the backup push server is a push server operated by an operating system provider of an application provider associated with the push client or a mobile terminal equipped with the push client, and a method of providing a communication service using the push server cloud .
delete 8. The method of claim 7,
Before the step of receiving the identification information of the push client
Further comprising: receiving a push service request message from the push client and transmitting the push server's IP address to the push client, and a communication service using the push server cloud Way.
8. The method of claim 7,
Wherein the application server provides authentication information (Authorization ID) to the push server to the push server, and a method of providing a communication service using the push server cloud.
In a mobile terminal using a push service,
An application control unit for modifying or changing an application or adding data using a push service;
A push client for controlling a push service of an application installed in the mobile terminal;
Wherein the push client controls to transmit identification information of the push client to a push service system including a push server, the push client receives push data from a backup push server or the push server And a transmitting /
Characterized in that if the push server fails to transmit the push data, the push client receives the push data from the backup push server,
The transmitting /
Wherein the push client controls the push server to receive the registration ID from the push server and send it to the app server.
A push server constituting a push service system,
A storage unit for storing push data to be used for a push service;
A transceiver for receiving identification information of a push client running on a mobile terminal from a push server or a second server constituting the push service system and transmitting push data to the push client; And
And a client verification unit for verifying a push client that uses the push service,
Wherein when the push server fails to transmit the push data, a backup push server constituting the push service system transmits the push data to the push client,
Wherein the sending / receiving unit transmits registration ID information (Registration ID) transmitted by the push client to the app server to the push client.

Images