Synchronization of application data in telecommunication system

Background of the Invention The present invention relates to data synchronization in an electric communication system, and more particularly to application data synchronization in a network system composed of at least one terminal, at least one synchronization server, and at least one database. Data synchronization is an operation in which at least two data collections are substantially matched with each other by the information units of the data collections after synchronization.

Data from mobile terminals such as portable computers, personal digital assistants (PDAs), mobile stations or pagers can be synchronized with network applications, desktop computer applications or other databases in telecommunications. Typically, data in particular calendar and email applications is synchronized. Traditionally, synchronization has been based on manufacturer-specific protocols that are incompatible with each other, limiting the use of terminals and the data types used, which has generally been difficult for users. Especially in mobile communication, it is important to obtain and update data regardless of the terminal or application to be used.

SyncML (Synchronization Markup Language) is based on XML (Extensible Markup Language) and is provided for improving application data synchronization. The SyncML synchronization protocol, which uses SyncML format messages, enables data synchronization in any application between any network terminals. For example, when you fill out a mobile station calendar, it automatically syncs with the calendar used by your company secretary. The SyncML sync protocol works on both wireless and wired networks and supports several forwarding protocols. SyncML synchronization protocol can be implemented, for example, HTTP protocol (Hyper Text Transfer Protocol), WAP (Wireless Application Protocol) standard WSP protocol (Wireless Session Protocol), USB (Universal Serial). TCP / IP (Transfer Control Protocol / Internet), the highest layer of the OBEX protocol used for cable connections such as Bus) and RS-232, short-range wireless frequency (Bluetooth®) connections, and infrared (IrDA) connections. The top of the Protocol) stack, as well as the top of the Simple Mail Transfer Protocol (SMTP).

Figure 1 shows an example of synchronization in which the mobile station MS functions as a SyncML client terminal and the network server S functions as a SyncML server. In the SyncML synchronization service, the synchronization session is first initialized to select, for example, the database to be synchronized. The SyncML client terminal MS is equipped with a sync client agent and sends a SyncML message (client update) containing information that has changed since the last synchronization, at least for the data to be synchronized by the mobile station MS. The SyncML server S has a Sync server agent that controls synchronization and a Sync engine, and usually waits for the SyncML client (MS) to start for synchronization. Server S synchronizes the data, that is, analyzes the updates made to the data in the database and client terminals, and makes the data consistent (makes necessary corrections, replacements, and deletions). The SyncML server S then returns the server update to the SyncML client (MS). The above example is simple but shows the role of the device in the SyncML standard. SyncML client terminals (MS) are typically mobile stations, personal computers (PCs), laptop computers, or personal digital assistants (PDAs). SyncML server S is generally a network server or PC.

Various synchronization-related settings must be defined for terminals that have a SyncML client agent before synchronization with the SyncML server is performed. Such settings include the SyncML server address and the address and type of database used. Users typically have several databases to synchronize with, each database requiring a separate setup. It is difficult and cumbersome for the user to manually register these settings or even accept the completed settings.<patcit num="1"><text>Japanese Unexamined Patent Publication No. 2000-20370</text></patcit><nplcit num="1"><text>Open Mobile Alliance, SyncML Sync Protocol, version 1.0, December 7, 2000</text></nplcit>

<p> An object of the present invention is to avoid the above problems and to make data synchronization in each terminal as easy as possible. An object of the present invention is achieved by methods, telecommunications systems, synchronization servers, telecommunications equipment, computer programs, and storage media characterized by the content of the independent claims. Preferred embodiments of the present invention are set forth in the dependent claims.</p>

<p> The present invention is based on the idea that one configuration message with at least the data required to enable synchronization is sent from the synchronization server to a terminal with a synchronization application, and that data includes at least one database configuration. Is based. The terminal can store the data in its memory and synchronization is performed using at least a portion of the stored data. Therefore, synchronous communication is set between the terminal and the synchronous server, and the synchronization is initialized by the set synchronous communication and at least a part of the data. Subsequently, at least the data in the first database and the second database (in the terminal) are synchronized based on at least a portion of the data. A "database" is a data collection of any data source or data storage that is understood in a broad sense, and the data collection can be updated by one or more applications. "Synchronous connection" refers to a transmission connection of logical data made to initiate synchronization. Synchronization initialization refers to the preparation for actual synchronization, for example, the initialization of a synchronization session according to the SyncML standard.</p><p> The settings according to the invention eliminate the need for the user to manually register the required settings, which are sent from the synchronization server and automatically populated for use on the terminal. This has the advantage of facilitating the operation and use of the synchronization service and making it as straightforward as possible for the user. The present invention is particularly advantageous when there are a plurality of databases, and the database setting of the terminal is completed at a time with one setting message. Therefore, the data transfer capacity can be reduced as much as possible.</p><p> According to a preferred embodiment of the invention, the database configuration consists of at least one database name and address, and information on the supported content types. If synchronization of database data is requested during synchronization initialization, the terminal sends the stored address to the synchronization server. This embodiment has the advantage that all the data that needs to be described in the database can be acquired from the server to the terminal, and the user does not have to register by himself / herself. Databases can be categorized by their type, for example, by each application, such as calendars and email, and by other criteria, whether the database is, for example, a personal calendar, a work calendar, or a group calendar. It can be classified according to whether or not. Content type refers to the format of data transfer during synchronization. Therefore, based on the content type supported by the database, the terminal will know if the data in the database will be synchronized through the server prior to the first synchronization. If the terminal and database support several of the same content types, the most desirable content type for synchronization will be selected on the terminal.</p><p> According to another preferred embodiment of the invention, the data includes user text so that the user text is displayed to the user of the terminal. Thus, each informative text is sent from the synchronization server so that the user can be informed and instructed.</p><p> According to yet another preferred embodiment of the invention, the data also includes a setting that determines the timing of synchronization, and the initialization of the synchronization session starts from the terminal based on the time of the setting. The advantage of this is that the timing of synchronization can be determined from the server (eg by the service provider) and the terminal can be prepared to automatically start synchronization with that setting.</p>

Hereinafter, preferred examples of the present invention in a system supporting the SyncML standard are shown, but the scope of application of the present invention is not limited thereto. The present invention can be applied to data synchronization in any system that supports any synchronization technique.

Figure 2 shows a network system capable of data synchronization in the database DB and terminal TE. For synchronization, the terminal TE functions as a client device. FIG. 2 shows two examples. In the first example, the terminal TE, the database DB, and the synchronization server S are connected to the local area network. The terminal TE connected to the local area network has a function such as a network interface card or software for controlling data communication in order to communicate with a device of the network LAN. The local area network LAN can be of any type, and the TE is typically connected to the server S via the Internet using a firewall FW. In the second example, the terminal TE, the synchronization server S, and the database DB are connected to the mobile network MNW. The terminal TE connected to the mobile network MNW has a mobile station function for wireless communication with the network MNW. Mobile network MNW is, for example, a network that supports GSM services and GPRS services (General Packet). Well-known networks that support Radio Service), third-generation mobile networks such as UMTS (Universal Mobile Telecommunication System) networks, wireless local area networks, WLANs, and private networks. It can be any wireless network. For clarity, Server S and Database DB are shown separately in Figure 2, but Server S can also function as a database DB.

Terminal TE (of wired network LAN and wireless network MNW) and server S are central processing units consisting of memory MEM; SMEM, user interface UI; SUI, input / output means IO; SIO for data communication, and one or more processors. It has a device CPU; SCPU. The memory MEM / SMEM includes a non-volatile unit for storing an application that controls the central processing unit CPU / SCPU, and a random access memory unit for data processing. The memory of TE's memory MEM (first database to be synchronized) and the memory of database DB hold the application data to be synchronized. The client agent CA operating according to the present invention is preferably implemented so that the computer program code stored in the memory MEM is executed by the CPU. Further, the synchronization server S provides the synchronization agent SA and the synchronization engine SE based on the present invention, preferably by executing the computer program code stored in the memory SMEM by the SCPU. When the computer program code is executed on the central processing unit CPU and SCPU, the terminal TE and the synchronization server S execute the functions of the invention. One example is shown in FIG. Computer programs are available over the network and / or can be stored on storage means such as discs, CD-ROM discs, or other external storage media, from which they are loaded into memory MEM / SMEM. Integrated circuits can also be used.

FIG. 3 shows a synchronization method according to an embodiment of the present invention. According to a preferred embodiment of the present invention, at least one configuration message is created on the synchronization server S (301). The server agent SA collects the data needed to process terminal TE synchronization and creates a configuration message CM. These data are preferably one or more database DB settings, especially database addresses and names, information on supported content types, or other database characteristics, start settings for synchronization start times, user instructions for synchronization, etc. Or the information of the server S, is included. Other database features include attributes that define, for example, whether the database is public or private (eg, a group calendar or a private calendar). The address of the database DB can be represented by either an absolute address or a relative address with respect to the server S. The data is generally stored in the memory SMEM of the synchronization server S, which reads them from the database when requested. The generation 301 of the setting message is started by the request of the service provider of the terminal TE or the local area network LAN or the mobile network MNW. The setting message is sent, for example, when the user brings in the terminal or registers with the service of the service provider. According to a preferred embodiment of the present invention, the setting message is automatically transmitted from the server S when the data required for synchronization is changed. For example, when the address of the database DB changes or when a new database is used, the server S sends a setting message including the new address and the setting of the new database to all the users of the database DB.

At least one generated configuration message is sent from synchronization server S to terminal TE (302). Upon receiving the configuration message, the TE stores at least a portion of the data in the message in the memory MEM (303), allowing the user interface UI to present possible user instructions.

The establishment of synchronous connection and synchronous session initialization can be started later at 304,305, at the synchronous start time determined by the start settings, based on the stored data. The start time can be determined by multiple methods, such as specific intervals. The synchronization service can also be started by the user or the synchronization server. Therefore, the database to be synchronized is determined by the instruction of the application or the user, or all the databases in which the settings are stored are synchronized. Data stored in memory MEM, such as database content type, is also used here. When the synchronization service is started under the initiative of Server S, the establishment of the logical synchronization connection is also started.

There are several advantages to using configuration messages: All the data needed for synchronization is sent at once, and device settings are automatically defined as soon as the configuration message is received, improving the usability of the synchronization service. To do. When all the necessary data is sent as one message, the resources of the network and terminals are effectively used, so that, for example, multiple authentications are not required.

When a synchronization service is requested, the client agent CA looks for data, especially database DB settings, in memory MEM (304). The client agent CA creates a client initialization message to establish a logical synchronization connection for communication, and the initialization message is sent from the terminal TE to the server S defined in the data. A logical synchronous connection is also established when the data communication itself is made by a connectionless protocol. A logically synchronized connection is built through the communication of initialization messages, otherwise the previous message is exchanged. In the initialization message, the synchronization server S synchronizes the data in which database, which synchronization type is used, and generally more information about authentication information and attributes of services and devices supported by the terminal TE. Will be informed. In addition, the user text is stored in memory MEM and displayed at this stage to inform the user of matters related to the synchronization being performed.

Upon receiving the initialization message, Server S responds to the initialization message and completes the initialization (306). The initialization message contains server device and authentication information. When the initialization is completed, the data in at least one database DB and the data in the terminal TE defined in the synchronization initialization are synchronized (307). The synchronization server S constructs data synchronization (307) using at least the data of the setting message sent from the terminal (305). Finally, the result of the synchronization is displayed to the user.

The synchronization types used are, for example: --Bidirectional synchronization --Slow synchronization --One-way synchronization from the client only --Playback synchronization from the client only --One-way synchronization from the server only --Playback synchronization from the server only --Server warning synchronization Is.

A more detailed description of synchronization sessions and synchronization data (307) initialization was embodied in the Standard SyncML Sync Protocol 1.0 Edition December 2000 for reference. However, the configuration messages of the present invention are used to transmit data related to synchronization using any synchronization method.

Synchronization (307), contrary to Figure 3, can be started without a separate initialization message (306-307). In such cases, initialization is performed at the same time as synchronization. However, configuration messages are used to define synchronization initialization settings and synchronization settings, as shown in Figure 3. Therefore, the number of messages sent is reduced.

FIG. 4 shows the content of the setting message according to the preferred embodiment of the present invention. Configuration messages are distinguished by a given type of a given MIME (Multipurpose Internet Mail Extensions) type attached to the message.

According to a preferred embodiment of the present invention, the format of the configuration message is XML. Therefore, the XML-formatted configuration message has data sent from the synchronization server S to the terminal TE in connection with the synchronization configuration, especially the execution of synchronization initialization. For configuration messages, the document type definition DTD defines what determines the tags used in the XML language, the components of the elements (! ELEMENT) between tags, and other XML document rules. As is well known in the XML language, elements can start with a start tag (eg &lt;Section&gt;), end with an end tag (eg &lt;/ Section&gt;), and contain text and other elements. The DTD is included in all configuration messages sent by the sync server, or the configuration message indicates a known DTD to the terminal TE. The DTD of a typical configuration message is shown below.

&lt;! ELEMENT SyncSetings (Version, HostAddr, Port ?, RemoteDB +, Name ?, Info ?, Auth *, ConRef ?, Condition?)&gt; &lt;! ELEMENT Version (#PCDATA)&gt; &lt;! ELEMENT HostAddr (#PCDATA)&gt; &lt;! ELEMENT Port (#PCDATA)&gt; &lt;! ELEMENT RemoteDB ((CTType, CTVer *) +, URI, Name?)&gt; &lt;! ELEMENT URI (#PCDATA)&gt; &lt;! ELEMENT CTType (#PCDATA)&gt; &lt;! ELEMENT CTVer (#) PCDATA)&gt; &lt;! ELEMENT URI (#PCDATA)&gt; &lt;! ELEMENT Name (#PCDATA)&gt; &lt;! ELEMENT Info (#PCDATA)&gt; &lt;! ELEMENT Auth (AuthLevel, AuthScheme,, ((Username | Cred) | (Username, Cred)))&gt; &lt;! ELEMENT AuthLevel (#PCDATA)&gt; &lt;! ELEMENT AuthScheme (#PCDATA)&gt; &lt;! ELEMENT Username (#PCDATA)&gt; &lt;! ELEMENT Cred (#PCDATA) &gt; &lt;! ELEMENT ConRef (ConType, ((Bearer ?, AddrType, Addr) | (RefID))&gt; &lt;! ELEMENT ConType (#PCDATA)&gt; &lt;! ELEMENT Bearer (#PCDATA)&gt; &lt;! ELEMENT AddrType (#PCDATA)&gt; &lt;! ELEMENT Addr (#PCDATA)&gt; &lt;! ELEMENT RefID (#PCDATA)&gt; &lt;! ELEMENT Condition (#PCDATA)&gt;

The question mark'?' Indicates that the particular element is optional. The'+' mark indicates that the element appears at least once. Not all elements are essential, and the present invention can be applied with elements different from those listed here. Each element of the setting message in FIG. 4 is described in detail below.

SyncSettings. A root element defined in the XML language that contains tags for other elements. Based on the root element, the message is specifically involved in configuration messages that contain data related to building synchronization.

Version. Defines the version of the configuration message format. If the format of the configuration message changes substantially, the version number must also change.

Name. Defines the display name of data (setting message) related to synchronization and database construction. When this element is used in the root element SyncSettings, it determines the name of its data. Determines the display name of the database when used inside a RemoteDB element. The display name can also be displayed to the user.

Host Addr. Contains the host address of the SyncML SyncML service (Service Agent SA). Generally, it is an IP address or URL, but a phone number or device tag can also be used.

Info. Contains text that is displayed to the user when a sync message is received (303) or thereafter (305). The user text is, for example, short information about the synchronization service or instructions for controlling the user's behavior. When used in the RemoteDB element, database-specific data can be displayed to the user.

Port. Defines the TCP port of Sync Server S (SyncML Sync Service). All configuration messages must support this element, and the default port number is 80 if this element is not defined.

Auth. Can contain four elements (AuthLevel, AuthScheme, ((UserName | Cred) | (UserName | Cred))) to define the authentication method and the credentials used in the SyncML session. It is used to authenticate the transport protocol layer, such as the HTTP and WAP protocol transport layers (WSP) and SyncML service authentication, and consists of authentication levels, authentication methods, user identifiers and credentials.

AuthLevel. Define the authentication level. The authentication level is represented numerically, for example as shown in Table 1.

<tables num="1"><img file="JP2008251047A_D0001.tif" /></tables>

AuthScheme. Defines the authentication method. The values are represented by the numbers defined in Table 2.

<tables num="2"><img file="JP2008251047A_D0002.tif" /></tables>

UserName. This element defines a username for authentication at the SyncML synchronization service level or transfer protocol level. The AuthLevel element defines the authentication level for any username.

Cred. Define credentials for authentication. The AuthLevel element defines the authentication level intended by the credential. If the authentication method is "basic" or "digest", the credentials include the password for the user identifier defined in the UserName element.

ConRef. This element is used with synchronization settings to define a reference with a physical or logical access point (connection reference). Contains ConType elements ((Bearer ?, AddrType, Addr) | (RefID)).

ConType. Define the connection type. The connection types are represented as shown in Table 3.

<tables num="3"><img file="JP2008251047A_D0003.tif" /></tables>

If the connection type is WAP 1.x server, HTTP / WAP 2.x proxy server, or logical access point, the content of the RefID element is used to define the connection reference. When a physical access point is used, the Bearer element, AddrType element, and Addr element determine the connection reference.

Bearer. Defines the bearer service type for the connection reference. The type of bearer service is defined, for example, in the manner shown in the table in Appendix 2, but is not limited to the bearer service type shown in the table.

AddrType. Defines the address type of the connection reference. Address types are represented numerically, as shown in Table 4.

<tables num="4"><img file="JP2008251047A_D0004.tif" /></tables>

Addr. Define the address of the connection reference. The address is, for example, a telephone number or an IP address. The type of address is defined in the AddrType element or based on the address value itself.

RefID. Defines a logical reference value for the connection reference. The reference value is either a logical name or another tag on the connection point.

RemoteDB. Define one or more databases with data to be synchronized. This element contains 5 elements ((CTType, CTVer *) +, URI, Name ?, Info?). This element also contains other definitions and user texts about the database.

URI. Defines a relative URI (Universal Resource Indicator) or absolute URI of the database. URIs are used to indicate which databases to synchronize in Sync alerts and synchronization commands, synchronization session initialization, and synchronization.

Since the URI element also has additional attributes, database and application attributes can be described in more detail. Additional attributes can be further identified, for example, by defining whether the calendar is personal, work, or family, for example, a textual identifier attached to a URI element (see Attachment 2). It can be defined by means or by using one or more specific elements. Additional attributes are represented in the URI element, as shown in "December 2000 SyncML Standard Chapter 4, 18, SyncML Representation Protocol Version 1.0". Therefore, there may be different types of databases with the same address (URI), but they are distinguished from each other by the additional attributes of the configuration message. Synchronization (304 to 307) is determined by various types of terminal TE database URIs, based on the data of this element, for example by using different initializations for different types.

CTTYpe. Defines the media content types that support the database. You can define the type of database in this way. Types include, for example, calendars, contacts, notes, short messages, multimedia messages, images, emails, or other types. The IANA (Internet Assigned Numbers Authority) media content types are listed on the WWW site http://www.isi.edu/in-notes/iana/assignments/media-types/media-types. This is used in this element. The value of this element is, for example, text / x-vcard, text / vcard, text / vcalendar, or text / vcalendar.

CTVer. Defines the supported content type version. This element is required if the content type, for example the MIME type, has several different versions (eg text / html 1.1 / 1.2 / 1.3).

It includes Condition. Parameters and the state related to the start of synchronization, and can determine, for example, to start synchronization every 5 hours.

According to a preferred embodiment of the present invention, the previous data regarding the database DB stored in the terminal TE can be added or replaced with new data based on the data of the setting message. Therefore, the setting message preferably has a field for determining whether it is related new data, replacement data, or additional data. This field allows the terminal TE to correctly store the data in the configuration message. To run this example, another tag, for example &lt;replace /&gt;, &lt;add /&gt;, &lt;new /&gt;, can be used under the root element SyncSettings.

This element is by no means limited to the above elements, and its application is not limited to XML format. For example, it is possible to send data of a setting message in HTML format. Attachment 2 shows a plaintext XML sample of the configuration message containing the above DTD elements.

The above elements include, but are not limited to, sending configuration messages based on preferred embodiments of the present invention, including references to the WAP standard (thus synchronization is preferably performed using the WSP protocol). HTTP and OBEX standards and lower layer communication technologies supported by such standards can be used.

According to a preferred embodiment of the present invention, the synchronization server S configuration message connected to the wireless telecommunications system is encoded in binary WBXML (Binary Binary XML) format (step 301). XML-formatted documents can be converted to WBXML format (or HTML format). Using the WBXML format has the advantage of reducing the required data communication capacity. This advantage is particularly advantageous in wireless interface communication. The WBXML format is preferred when the configuration message is sent using a mechanism with limited data communication capacity, such as short message service SMS. Attachment 3 represents the token allocation for pasting the above elements into WBXML format.

In the case of communication using the push service of the WAP protocol, the setting message is assigned to a predetermined WDP (Wireless Datagram Protocol) port. Terminal TE must listen on this port. Communication at the lower layers can be any communication protocol supported by the WAP protocol, such as SMS or other signaling communication methods (eg USSD: Unstructured Supplementary Service Data), or circuit-switched data calls or packet data communication services. Etc. can be used.

It is clear to those skilled in the art that as technological developments, the basic ideas of the present invention can be implemented in multiple ways. Therefore, the present invention and the examples are not limited to the above examples, and can be modified within the scope of the claims.

<tables num="5"><img file="JP2008251047A_D0005.tif" /></tables>

Annex 2. &lt;SyncSettings&gt; &lt;Version&gt; 1.0 &lt;/ Version&gt; &lt;Name&gt; Synchronization Server &lt;/ Name&gt; &lt;HostAddr&gt; http://www.syncserver.com/sync &lt;/ HostAddr&gt; &lt;Info&gt; This is a synchronization server for your use. &lt;/ Info&gt; &lt;Port&gt; 8080 &lt;/ Port&gt; &lt;Auth&gt; &lt;AuthLevel&gt; 3 &lt;/ AuthLevel&gt; &lt;AuthScheme&gt; 1 &lt;/ AuthScheme&gt; &lt;Username&gt; virtanen &lt;/ Username&gt; &lt;Cred&gt; password &lt;/ Cred&gt; &lt;/ Auth &gt; &lt;Auth&gt; &lt;AuthLevel&gt; 1 &lt;/ AuthLevel&gt; &lt;AuthScheme&gt; 1 &lt;/ AuthScheme&gt; &lt;Username&gt; mvirtan &lt;/ Username&gt; &lt;Cred&gt; password &lt;/ Cred&gt; &lt;/ Auth&gt; &lt;ConRef&gt; &lt;ConType&gt; 1 &lt;/ ConType&gt; &lt;RefID&gt; Nokia AP &lt;/ RefID&gt; &lt;/ ConRef&gt; &lt;RemoteDB&gt; &lt;URI&gt; ./Contacts?CLASS&amp;EQ;PRIVATE &lt;URI/&gt; &lt;CTType&gt; text / x-vcard &lt;/ CTType&gt; &lt;CTVer&gt; 2.1 &lt;/ CTVer&gt; &lt;Name&gt; Private Contact DB &lt;/ Name&gt; &lt;/ RemoteDB&gt; &lt;RemoteDB&gt; &lt;URI &gt; ./Calendar &lt;/ URI&gt; &lt;CTType&gt; text / x-vcalendar &lt;/ CTType&gt; &lt;CTVer&gt; 1.0 &lt;/ CTVer&gt; &lt;Name&gt; Calendar DB &lt;/ Name&gt; &lt;/ RemoteDB&gt; &lt;Condition&gt; Every fifth hours &lt;/ Condition&gt; &lt;/ SyncSettings&gt;

<tables num="6"><img file="JP2008251047A_D0006.tif" /></tables>

<figref num="1">Figure 1 shows synchronization using the SyncML synchronization protocol.</figref><figref num="2">FIG. 2 is a diagram showing a wireless network and a local area network.</figref><figref num="3">FIG. 3 is a diagram showing a method according to a preferred embodiment of the present invention.</figref><figref num="4">FIG. 4 is a diagram showing a setting message according to a preferred embodiment of the present invention.</figref>