EP2057820A2

EP2057820A2 - Device and method for producing a data supply

Info

Publication number: EP2057820A2
Application number: EP07825447A
Authority: EP
Inventors: Roger Plieske; Lars Rademacher
Original assignee: Palm Inc
Current assignee: Qualcomm Inc
Priority date: 2006-08-08
Filing date: 2007-08-08
Publication date: 2009-05-13
Also published as: WO2008017959A3; DE102006037029A1; WO2008017959A2

Abstract

The invention relates to a device and a method for producing a data supply, having a first data connection interface (1) for producing a data connection (http) to a server (S), via which data (W(KP) ) which are encoded in accordance with a first transport protocol can be received. A first transport protocol unit (2) carries out a data transport (O{W(KP) }) of the encoded data (W(KP) ) on the data connection (http) in accordance with a second transport protocol. A second transport protocol unit (3) subsequently carries out decoding of the encoded data (W(KP) ) in accordance with the first transport protocol, whereby the original supply data (KP) are produced. A very cost-effective data supply is thereby obtained.

Description

DEVICE AND METHOD FOR PRODUCING A DATA SUPPLY

The present invention relates to a device and a method for producing a data supply and in particular to a device and a method for producing a data supply for mobile telecommunications terminals via a packet switching network.

In particular the use of mobile telecommunications terminals has been increasing significantly in recent years. Mobile telecommunications terminals, such as, for example, mobile telephones, smartphones and so- called PDAs (Personal Digital Assistants) are changing from relatively simple terminals with individual functions into increasingly complex devices having telephone and PDA capabilities. However, with these improvements, there is a greater requirement in terms of configurability and maintenance.

It is therefore often necessary to change configuration settings which are stored on the mobile telecommunications terminals. For example, it may be the case that a service provider has to change the configuration settings of a subscriber in response to a change in service, or a setting which relates to a predetermined application in the terminal may require a modification.

Generally, a data supply of this type for mobile telecommunications terminals in order to carry out a corresponding configuration is enabled by means of so- called OTAP (Over The Air Provisioning) . For example, it is possible, via an SMS connection (Short Message Service) , to transmit configuration data from a server via a network to a telecommunications terminal, in order to thereby enable a corresponding configuration of a service and/or the terminal. However, such a conventional configuration of telecommunications terminals via an SMS connection also brings about extremely high costs for the provider of the configuration parameters, since a considerable number of SMS or short messages are sometimes required in order to transfer a complete configuration data set to a mobile terminal .

The object of the invention is therefore to provide a device and method for producing a data supply which allow a significant reduction of the costs, at least for the provider of the configuration data. This object is achieved according to the invention with respect to the device by the features of claim 1 and with respect to the method by the measures of claim 18.

According to the invention, a first data connection interface consequently produces a data connection to a server, via which connection data encoded in accordance with a first transport protocol are received. A first transport protocol unit carries out a data transport of the encoded data on the data connection in accordance with a second transport protocol. Finally, in a second transport protocol unit, the encoded data are decoded in accordance with the first transport protocol, whereby the actual supply data are produced. When appropriate transport protocols are used, the data structures are produced in a particularly simple manner, with the data transport at the same time being very simple and cost- effective.

For example, the first data connection interface is an "http" interface and the first transport protocol is a document-based protocol for parametrising clients. In particular, the first transport protocol may be an "Open Wave Provisioning", "OTAP 7.0" or "OMA-CP" protocol. The second transport protocol is, for example, a session-based, protocol for parametrising clients and in particular the "OMA-DM" protocol. With a specific implementation of this type, it is possible to use the protocol structures which are often already provided in conventional mobile telecommunications terminals, a cost-effective data supply being enabled for data transfer. An "OMA-DM" client is therefore preferably used as a first transport protocol unit and has a referencing of the second transport protocol unit to a node of the "OMA-DM" tree structure thereof . Technical implementation is further simplified thereby.

As an alternative to this, it is also possible to use, as a first transport protocol unit, an "OMA-DL" client which, as the transfer location for the second transport protocol unit, establishes a predetermined storage location. In this instance, an appropriate configuration data set can be downloaded into the terminal via a uni-directional connection.

Furthermore, the "OMA-DM" client may have, in a node of its "OMA-DM" tree structure, a terminal identification means which allows authentication of the encoded data. In this manner, it is possible to ensure that only the data that are sent by a predetermined server are accepted in a respective terminal as configuration data.

Furthermore, it is possible to provide a second data connection interface for producing a data connection to the server, via which the data which are encoded in accordance with the first transport protocol are also transferred in accordance with the first transport protocol. Preferably, it is consequently possible to transmit WAP Push messages via an SMS client which allows an initial configuration of the data supply according to the invention via an SMS data connection interface which is generally available in every terminal .

Furthermore, it is possible to provide a third connection interface for producing a data connection, via which data which are encoded in accordance with any transport protocol or even non-encoded supply data are transferred. Data connection interfaces of this type are, for example, Bluetooth, WLAN, IrDA, USB or RS232, via which, for example, in a service department or in a repair shop, respective configuration data can be rapidly and readily loaded.

With regard to the method for producing a data supply, the supply data are first encoded in accordance with a first transport protocol in order to produce encoded data, a data transport of the encoded data is subsequently carried out in accordance with a second transport protocol and, finally, the encoded data are decoded again in accordance with the first transport protocol in order to recover the supply data. In particular with a combination of OMA- CP and OMA-DM transport protocols, it is thereby possible to provide a particularly effective and cost-effective data supply, in particular for mobile telecommunications terminals .

Further advantageous configurations of the invention are characterised in the other subsidiary claims.

The invention is described in greater detail below with reference to embodiments and with reference to the drawings, in which:

Figure 1 is a simplified illustration of a client/server system for producing the data supply according to the invention;

Figure 2 is a simplified block diagram to illustrate significant function blocks of the structure illustrated in Figure 1 in accordance with a first embodiment;

Figure 3 is a simplified block diagram of a device for producing a data supply in accordance with a second embodiment ; and

Figure 4 is a simplified flow diagram to illustrate significant steps of the method according to the invention.

Figure 1 is a simplified illustration of a so-called client/server system in which the present invention can, for example, be implemented.

According to Figure 1, from a server S, such as, for example, a configuration server, configuration data are made available in this instance to a telecommunications terminal TE via a network N so that the terminal can, for example, implement an e-mail service (electronic mail) with no complex inputting of configuration data in a simple and user-friendly- manner. The network N may in this instance have a circuit switching network and/or a packet switching network, such as, for example, the Internet. The telecommunications terminal TE is, for example, a wireless terminal, such as, for example, a mobile telephone, smartphone or a so-called PDA which are connected to the network N via a mobile communications network (not illustrated) . However, the telecommunications terminal TE may also be a wire- connected terminal, such as, for example, a PC.

Figure 2 is a simplified block diagram of the system illustrated in Figure 1. According to Figure 2, the configuration server S has a setting store 7 which, for example, provides the configuration parameters KP necessary for configuring a terminal as supply data. Those supply data or configuration parameters KP are encoded by an encoding unit 8 in accordance with a first transport protocol, whereby encoded data W(KP) are produced. For example, a so-called OTAP encoder (Over The Air Provisioning) is used as an encoding unit 8 in the configuration server S. The so-called "OMA-CP" transport protocol (Open Mobile Alliance - Client Provisioning) is preferably used as the first transport protocol in order to produce so- called "WAP Push" messages (Wireless Application Protocol) , it being possible for the WAP Push messages to contain the encoded data or configuration parameters KP. Those configuration parameters KP encoded in a WAP Push message W(KP) are subsequently supplied to a server-side OMA-DM protocol unit (Open Mobile Alliance - Device Management) which carries out via a server-side data connection interface 10 a session-based data connection, such as, for example, an "http" connection (hypertext transfer protocol) via the network N with respect to the telecommunications terminal TE.

The data or WAP Push messages W(KP) encoded in accordance with the first transport protocol are consequently transferred via the bi-directional "http" connection using a second transport protocol, that is, the OMA-DM protocol θ{W(KP)}.

A first data connection interface 1 for producing a terminal-side data connection to the configuration server S or the data connection interface 10 thereof is located in the mobile telecommunications terminal TE. Furthermore, the terminal TE has a first transport protocol unit 2 for bringing about data transport of the encoded data or WAP Push messages on the "http" data connection in accordance with a second transport protocol. The second transport protocol is a session- based protocol for parametrising clients in this instance. A so-called OMA-DM client (Open Mobile Alliance - Device Management) is preferably used as the first transport protocol unit 2 in order to carry out an "OMA-DM" protocol, whereby the data or WAP Push messages W(KP) encoded in accordance with the first transport protocol can be transferred via the network N in a particularly cost-effective manner. However, the configuration parameters KP are not resolved in the extremely complex tree structure which is conventional for OMA-DM but instead are supplied as a whole to a node of the "OMA-DM" tree structure which can subsequently be read out by a second transport protocol unit 3.

The second transport protocol unit 3 substantially serves to decode the encoded data or the WAP Push messages W(KP) in accordance with the first transport protocol, whereby the original supply data or configuration parameters KP are again obtained. These can subsequently be stored in a registration store or "registry" 4 which allows the mobile telecommunications terminal TE or a respective service to be configured.

According to the invention, supply data or configuration parameters to be transferred are consequently first encoded in accordance with a first transport protocol and subsequently transferred in accordance with a second transport protocol in order finally to be decoded again in accordance with the first transport protocol. The first transport protocol is a document-based protocol for parametrising clients in this instance. The so-called "Open Wave Provisioning" protocol from the company Open Wave, the "OTAP 7.0" protocol from the company Nokia or the "OMA-CP" protocol (Open Mobile Alliance - Client Provisioning) are preferably used as the first transport protocol.

Accordingly, the supply data or configuration parameters encoded in this manner are transferred via the network N in accordance with the second transport protocol, with, for example, a session-based protocol being used for parametrising clients and in particular the "OMA-DM" protocol (Open Mobile Alliance - Device Management) being used.

Although the "OMA-DM" client 2 preferably provides a node of its "OMA-DM" tree structure as a transfer location for the WAP Push client (Wireless Application Protocol) 3, referencing, that is to say, direct association, of the second transport protocol unit 3 or the WAP Push client to/with a node of the "OMA-DM" tree structure can also take place in the "OMA-DM" client 2. In this instance, the OMA-DM client 2 assigns a node of its tree structure to the input box of the WAP Push client 3 , the server S then being able to transmit a WAP Push message via the OMA-DM server 9 and transmitting an ADD command for that node. Executing such an ADD command places an object in the WAP Push input box and can optionally instruct the WAP Push client 3 directly afterwards to process that object. A piece of status information, such as, for example, success confirmation or error information could thereby be transmitted to the server S, which is not generally possible if WAP Push messages are transmitted via an SMS connection. The "OMA-DM" client 2 can further optionally have in a node of its "OMA-DM" tree structure a terminal identification means which allows authentication of the encoded data or the WAP push messages W(KP) . Such a terminal identification means can be, for example, an IMSI (International Mobile Subscriber Identity) which, for example, in mobile communications networks in accordance with the GSM standard (Global System for Mobile Communications) , is a number which clearly identifies a subscriber to a mobile communications service. For example, a NETWPIN authentication can be carried out as authentication for WAP Push messages and is particularly user-friendly.

In accordance with Figure 2, it is further possible for a second data connection interface 5 to be provided in order to produce a data connection to the server S, via which the data or WAP Push messages W(KP) which are encoded in accordance with the first transport protocol are transferred in accordance with the first transport protocol. That second data connection interface 5 is preferably an SMS interface for producing an SMS connection. Such SMS data connection interfaces or SMS clients 5 are generally produced in each mobile telecommunications terminal in any case because they constitute the only possibility of automatically configuring a terminal which is not configured at first by means of a server S. Therefore, an initial configuration is preferably carried out first for the data supply according to the invention via that SMS data connection interface 5 or the SMS client, a corresponding SMS server 11 transferring at the server side the data or WAP Push messages which are also encoded in accordance with the first transport protocol. Such an initial configuration is also referred to as "Bootstrapping" . As soon as the telecommunications terminal TE has been configured according to the invention, a more extensive data supply can subsequently be carried out by means of the cost-effective "http" connection in accordance with, for example, OMA-DM. In principle, it would also be possible for an e-mail data connection interface to be provided as the second data connection interface 5 , with the data being transferred in an e-mail message.

In accordance with Figure 2 , a third data connection interface 6 can further be provided to produce an additional data connection, via which data encoded in accordance with any transport protocol or even non- encoded supply data or configuration parameters KP can be transferred. Such a data connection interface is, for example, a Bluetooth, WLAN (Wireless Local Area Network) , IrDA, USB or RS232 interface which allows an associated connection. In particular for repair or maintenance work, it is possible for simple and very effective configuration of the telecommunications terminal TE to be carried out via a third data connection interface 6 of this type. In this instance, the parameters KP received accordingly can again be written directly to the registration store 4.

Consequently, any desired transport mechanism can be used to transfer, for example, WAP Push messages to a terminal. The WAP Push messages can be, for example, XML-encoded (extended Markup Language) OTAP documents (Over The Air Provisioning) . The first transport protocol unit 2 extracts the original WAP Push message in this instance and forwards it to the second transport protocol unit or the WAP Push client 3 which, in turn, further processes the document in accordance with its standard procedures .

An OTAP document, such as, for example, a WAP Push message is consequently transferred via an "http" connection to the OMA-DM client 2 of the mobile terminal TE using the OMA-DM server 9 as a wrapper or envelope. The OMA-DM client 2 subsequently extracts the WAP Push message and transmits it to the WAP Push client 3 using the same interfaces as an SMS client 5 normally uses . The WAP Push client 3 subsequently processes the document and writes the settings or the configuration parameters KP to the registration store 4 , whereby the configuration of the terminal TE is carried out or made possible.

Figure 3 is a simplified block diagram of a device for producing a data supply in accordance with a second embodiment, with the same reference numerals referring to the same or corresponding elements, for which reason they will not be described again below.

In accordance with Figure 3 an "OMA-DL" client 2A (Open Mobile Alliance - DownLoad) can also be used as the first transport protocol unit, with a predetermined storage location 2B being established in a telecommunications terminal as a transfer location for the second transport protocol unit or the WAP Push client 3. With such an OMA-DL client 2A having an associated storage location 2B, it is possible to produce an OMA download mechanism which allows, for example, WAP Push messages to be downloaded to a predetermined location in the file system of the terminal. In this instance, that storage location 2B is defined by an agreement as a transfer location for the WAP Push client 3. As an alternative to the OMA-DL client, a download mechanism can also be brought about using existing WAP or HTML browsers which exist in the terminal TE or can be produced.

In this manner, supply data, such as, for example, configuration parameters no longer have to be transferred via cost-intensive short messages (SMS) , but instead can be exchanged or transferred via corresponding cost-effective data connections. Owing to the encoding in a first transport protocol, such as, for example, a binary WBXML document, the configuration parameters can be transferred substantially more quickly than when only an OMA-DM architecture is used. Furthermore, in contrast to unidirectional SMS messages, interactive features can be produced which allow, for example, feedback for the transferred configuration parameters to the server S.

It is further possible to have access to a large number of already existing function blocks both at the server side and at the terminal side, for which reason only slight modifications are necessary and consequently costs can further be reduced. Implementation which is very rapid and simple as well as cost-effective is thereby brought about for data supply from a server to a telecommunications terminal .

Figure 4 is a simplified flow diagram for illustrating significant steps of the method according to the invention.

After starting at step SO, the supply data, such as, for example, configuration parameters KP are first encoded in accordance with a first transport protocol in order to produce encoded data W(KP) . For example, a single binary WBXML document is produced and is accommodated in a WAP Push message. In steps S2 and S3, data transport of the data W(KP) encoded in this manner is subsequently carried out in accordance with a second transport protocol. More precisely, for example, an http data connection is preferably produced between a server S and a terminal TE using an OMA-DM protocol, whereby the reduced costs are substantially achieved. In a step S4, the data W(KP) which are transferred in this manner and which are still encoded are subsequently decoded in accordance with, the first transport protocol in order to recover the original supply data or configuration parameters KP.

This takes place, for example, in the WAP Push client 3 of the terminal. Finally, in a step S5, the terminal TE is configured for a predetermined service, with the decoded supply data or configuration parameters, for example, being written to a registration store. The method ends at step S6.

The invention has been described above with reference to an "http" connection as a cost-effective data connection. However, it is not limited thereto and similarly also includes other session-based data connections .

List of reference numerals

1 First data connection interface

2 First transport protocol unit

3 Second transport protocol unit

4 Registration store

5 Second data connection interface

6 Third data connection interface

7 Setting store

8 Encoder

9 Server-side transport protocol unit

10 Server-side first data connection interface

11 Server-side second data connection interface S Server

TE Telecommunications terminal

2A OMA-DL client

2B DL storage location

KP Configuration parameters

W(KP) Encoded data

O {w(KP)} Data encoded in accordance with second transport protocol

N Network

SO to S6 Method steps

Claims

1. Device for producing a data supply having:

a first data connection interface (1) for producing a data connection (http) to a server (S) , via which data (W(KP)) encoded in accordance with a first transport protocol are received;

a first transport protocol unit (2) for carrying out a data transport of the encoded data (W(KP)) on the data connection (http) in accordance with a second transport protocol ; and

a second transport protocol unit (3) for carrying out decoding of the encoded data (W(KP)) in accordance with the first transport protocol for producing supply data (KP) .

2. Device according to claim 1, characterised by a registration store (4) for storing the supply data (KP) .

3. Device according to either claim 1 or claim 2 , characterised by a second data connection interface 003149

22

(5) for producing a data connection (SMS) to the server (S) , via which the data encoded in accordance with the first transport protocol are transferred in accordance with the first transport protocol.

4. Device according to any one of claims 1 to 3 , characterised by a third data connection interface (6) for producing a data connection (Bluetooth) , via which data encoded in accordance with any transport protocol or non-encoded supply data (KP) are transferred.

5. Device according to any one of claims 1 to 4, characterised in that the first data connection interface (1) is an http interface.

6. Device according to any one of claims 1 to 5 , characterised in that the second data connection interface (5) is an SMS or e-mail interface.

7. Device according to any one of claims 1 to 6, characterised in that the third data connection interface (6) is a Bluetooth, WLAN, IrDA, USB or RS232 interface .

8. Device according to any one of claims 1 to 7, characterised in that the first transport protocol is a document-based protocol for parametrising clients.

9. Device according to claim 8, characterised in that the first transport protocol is the "Open Wave Provisioning", "OTAP 7.0" or "OMA-CP" protocol.

10. Device according to any one of claims 1 to 9, characterised in that the second transport protocol is a session-based protocol for parametrising clients .

11. Device according to claim 10, characterised in that the second transport protocol is the "OMA-DM" protocol .

12. Device according to any one of claims 1 to 11, characterised in that the first transport protocol unit (3) is an "OMA-DM" client.

13. Device according to claim 12, characterised in that the "OMA-DM" client (2) has referencing of the second transport protocol unit (3) to a node of the "OMA-DM" tree structure thereof.

14. Device according to any one of claims 1 to 13, characterised in that the "OMA-DM" client (2) has, in a node of its "OMA-DM" tree structure, a terminal identification means which allows authentication of the encoded data (W(KP)) .

15. Device according to any one of claims 1 to 11, characterised in that the first transport protocol unit is an "OMA-DL" client (2A) having a storage location (2B) which is established as a transfer location for the second transport protocol unit (3) .

16. Device according to any one of claims 1 to 15, characterised in that the encoded data (W(KP)) are a "WAP Push" message.

17. Device according to any one of claims 1 to 16, characterised in that the supply data (KP) are configuration parameters for a mobile telecommunications terminal (TE) .

18. Method for producing a data supply having the steps:

encoding (Sl) supply data (KP) in accordance with a first transport protocol for producing encoded data IB2007/003149

25 (W (KP) ) ;

carrying out (S2, S3) a data transport (θ{W(KP)}) of the encoded data (W(KP)) in accordance with a second transport protocol ; and

decoding (S4) the encoded data (W(KP)) in accordance with the first transport protocol in order to recover the supply data (KP) .

19. Method according to claim 18, characterised by the additional step:

configuring (S5) a telecommunications terminal (TE) with the recovered supply data (KP) .

20. Method according to either claim 18 or claim 19, characterised in that the data transport is carried out via an http connection.

21. Method according to any one of claims 18 to 20, characterised in that the first transport protocol is a document-based protocol for parametrising clients.

22. Method according to claim 21, characterised in that the first transport protocol is the "Open Wave Provisioning", "OTAP 7.0" or "OMA-CP" protocol.

23. Method according to any one of claims 18 to 22, characterised in that the second transport protocol is a session-based protocol for parametrising clients.

24. Method according to claim 23, characterised in that the second transport protocol is the "OMA-DM" protocol .

25. Method according to any one of claims 18 to 24, characterised in that during the data transport an "OMA-DM" client carries out referencing of the second transport protocol unit (3) to a node of the "OMA-DM" tree structure thereof .

26. Method according to any one of claims 18 to 25, characterised in that during the data transport the "OMA-DM" client has, in a node of its "OMA-DM" tree structure, a terminal identification means which allows authentication of the encoded data (W(KP)) .

27. Method according to any one of claims 18 to 26, characterised in that during the data transport an "OMA-DL" download is carried out .

28. Method according to any one of claims 18 to 27, characterised in that the encoded data (W(KP)) are a "WAP Push" message.

29. Method according to any one of claims 18 to 28, characterised in that the supply data (KP) are configuration parameters for a mobile telecommunications terminal (TE) .