US20100017520A1 - Data synchronization - Google Patents
Data synchronization Download PDFInfo
- Publication number
- US20100017520A1 US20100017520A1 US12/503,996 US50399609A US2010017520A1 US 20100017520 A1 US20100017520 A1 US 20100017520A1 US 50399609 A US50399609 A US 50399609A US 2010017520 A1 US2010017520 A1 US 2010017520A1
- Authority
- US
- United States
- Prior art keywords
- synchronization
- syncml
- message size
- maximum message
- size
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
Definitions
- the invention relates to data synchronization between two or more synchronization devices, particularly to limiting the size of synchronization messages during a synchronization session.
- Data synchronization is an operation in which a correspondence between at least two data collections is created in such a way that after the synchronization the units of the data collections substantially correspond to each other.
- Data of portable terminals such as portable computers, PDA (Personal Digital Assistant) devices, mobile stations or pagers
- PDA Personal Digital Assistant
- network applications desktop computer applications or other databases in a telecommunications system.
- Data of calendar and e-mail applications in particular, are synchronized. Synchronization has previously been based on different proprietary protocols which are not compatible with each other. This restricts the use of terminal or data types and often causes problems to the user.
- mobile communication in particular, it is important to acquire and update data irrespective of the terminal or application used.
- the SyncML Synchronization Markup Language
- XML Extensible Markup Language
- the SyncML synchronization protocol using messages in the SyncML format allows synchronization of data in any application between any networked terminals. For example, a calendar entry in a mobile station is automatically synchronized with the network calendar used by a company secretary.
- FIG. 1 shows an example of synchronization where a mobile station MS functions as the SyncML client terminal and a network server S functions as the SyncML server.
- the SyncML synchronization service comprises first initializing a synchronization session during which e.g. the database to be synchronized is selected.
- the SyncML client terminal MS synchronization application layer functions are provided by a synchronization client agent, which implements the SyncML protocol inter alia by sending a SyncML package (Client Modifications), which includes, in one or more SyncML messages, modifications made after the last synchronization session to the data that is the object of synchronization in the mobile station MS.
- a SyncML package Client Modifications
- the SyncML server S synchronization application layer functions are provided by a sync server agent, which controls synchronization, and a synchronization block (Sync Engine).
- the server usually waits for an initiative for synchronization from the SyncML client (MS).
- the server S synchronizes the data, i.e. analyses the changes made to the database and client terminal data, and harmonizes it (makes necessary modifications, replacements and deletions). After this, the SyncML server S sends the server modifications back to the SyncML client (MS).
- the example described above is simple, yet it illustrates the roles of the devices according to the SyncML standard.
- the SyncML client terminal (MS) is typically a mobile station (MS), a PC (Personal Computer), a laptop, or a PDA device.
- the SyncML server S is typically a network server or a PC.
- the SyncML synchronization protocol operates in both wireless and wired networks and supports several transfer protocols.
- the SyncML synchronization protocol can be implemented, for example, on top of the HTTP protocol (Hyper Text Transfer Protocol), the WSP protocol (Wireless Session Protocol) of the WAP (Wireless Application Protocol) standard, the OBEX protocol used for cable links, such as the USB (Universal Serial Bus) or RS-232, or for short-range radio frequency (Bluetooth) links or infrared (IrDA) links, on top of a TCP/IP (Transport Control Protocol/Internet Protocol) stack, and also on top of an e-mail protocol (SMTP, Simple Mail Transfer Protocol).
- HTTP Hyper Text Transfer Protocol
- WSP protocol Wireless Session Protocol
- WAP Wireless Application Protocol
- OBEX protocol used for cable links, such as the USB (Universal Serial Bus) or RS-232, or for short-range radio frequency (Bluetooth) links or infrared (IrDA) links
- TCP/IP Transmission Control Protocol
- the SyncML consists of end-to-end transmission of SyncML messages and it has to function even though a plurality of transport layer protocols is used.
- the devices are not typically aware of the message size they should use when sending synchronization messages to each other. If a device sends a large SyncML message, it is possible that the transport layer is not able to deliver it or a receiving device is not able to process it after it has arrived.
- An object of the invention is to avoid the problem described above and to provide means for limiting the size of transferred synchronization messages.
- the objects of the invention are achieved with a method, a synchronization system, synchronization devices, and computer program products which are characterized by what is disclosed in the independent claims.
- the preferred embodiments of the invention are disclosed in the dependent claims.
- the invention is based on determining maximum message size for synchronization messages.
- a first device specifies a maximum message size for synchronization messages to be sent to the first device and transmits information on the maximum message size to a second device.
- the second device transmits to the first device synchronization messages that do not exceed the maximum message size.
- the arrangement of the invention has the advantage that the reliability of synchronization is improved as the problems caused by too large synchronization messages are avoided. If there is a large amount of synchronization data to be transferred, the data can be divided into multiple synchronization messages according to the capabilities of the receiving device.
- synchronization message refers generally to messages composed at the application layer by a synchronization application entity and comprising synchronization-related data.
- the synchronization messages are sent to lower layers (transport layer) for transmission, where they are changed into transport layer packets.
- transport layer transport layer
- the SyncML protocol is used.
- the SyncML synchronization message may contain SyncML commands, as well as the related synchronization data and meta information.
- the maximum messages sizes are determined in both devices of a synchronization session and the smaller value is chosen as the maximum message size for synchronization messages in both directions. This embodiment further improves the reliability of the synchronization session.
- the first device is a mobile station and the second device is a synchronization server.
- the limited resources, especially temporary memory resources, of mobile stations can be taken into account already at the synchronization application level.
- the maximum message size is determined based on the limitations of a transport layer providing transport of the synchronization messages. This allows the limitations of intermediary devices, such as a WAP gateway, to be considered when determining the maximum message size for synchronization messages.
- FIG. 1 illustrates synchronization according to the SyncML synchronization protocol
- FIG. 2 a illustrates a wireless network and a local area network
- FIG. 2 b illustrates a SyncML client and a SyncML server
- FIG. 3 illustrates a method according to a preferred embodiment of the invention.
- FIG. 4 is a signaling chart illustrating signaling events according to preferred embodiments of the invention.
- FIG. 2 a illustrates a networked system where data of databases DB and terminals TE can be synchronized.
- the terminal TE functions as a client device.
- FIG. 2 a shows two examples. In the first one there are terminals TE, databases DB and synchronization servers S connected to a local area network LAN.
- the terminal TE connected to the network LAN comprises a functionality for communicating with the devices of the network LAN, e.g. a network card and software which controls data transmission.
- the local area network LAN can be a local area network of any type and the TE can also communicate with the server S via the Internet, typically through a firewall FW.
- a terminal TE, a synchronization server S and databases DB are connected to a mobile network MNW.
- the terminal TE connected to the network MNW comprises a mobile station functionality for communicating wirelessly with the network MNW.
- the mobile network MNW can be any prior art wireless network, such as a network supporting the GSM service, a network supporting also the GPRS service (General Packet Radio Service), a third-generation mobile communication network, such as a UMTS network (Universal Mobile Telecommunications System), a wireless local area network WLAN or a private network.
- the server S can also function as a database DB, even though in FIG. 2 a the servers S and the databases DB are shown separately for the sake of clarity.
- database is to be understood broadly as referring to a data collection of any data source or data storage that can be updated by one or more applications.
- the terminals TE in wired networks LAN and in wireless networks MNW
- the servers S comprise a memory MEM; SMEM, a user interface UI; SUI, I/O means I/O; SI/O for arranging data transmission and a central processing unit CPU; SCPU, which comprises one or more processors.
- the memory MEM; SMEM includes a nonvolatile portion for storing applications controlling the central processor (CPU; SCPU) and a volatile memory portion for data processing.
- the memory MEM of the TE (which in this example is the database to be synchronized) and the memory of the databases DB store application data which are to be synchronized.
- a client agent CA providing the application layer functionality according to the invention is preferably implemented by executing a computer program code stored in the memory MEM in the CPU.
- the synchronization server S provides a synchronization agent SA and a synchronization engine SE to provide the synchronization application layer functionality.
- the TE and the S further comprise protocol entities providing the transport means for SyncML application layer data, especially the transport layer protocol entities TTE and STE utilizing the I/O means I/O; SI/O.
- the transport layer generally refers to a layer which provides the synchronization application layer with a reliable logical data transmission connection (not necessarily a protocol of the transport layer according to the OSI model, such as the TCP).
- the computer program code when executed in the central processing unit CPU and the SCPU, causes the terminal TE and the synchronization server S to implement the inventive means. Embodiments of these means are illustrated in FIGS. 3 and 4 .
- the computer programs can be embedded or obtained via a network and/or stored in memory means, such as a floppy disk, a CD ROM or other external memory means, from which they can be loaded into the memory MEM, SMEM. It is also possible to use hardware solutions or a combination of both software and hardware solutions to implement the inventive means.
- FIG. 3 illustrates a method according to a preferred embodiment of the invention.
- transport layer-specific and/or SyncML implementation-specific limitations are determined 302 .
- the need for determining the maximum message size 301 typically exists as a SyncML session is initiated, but it is possible to determine the maximum message size at any stage of the SyncML session.
- the term ‘synchronization session’ generally refers to the end-to-end communication between at least two synchronization protocol entities for synchronizing data between at least two devices, without being limited to the SyncML session.
- the SyncML implementation-specific limitations may be limitations affecting the functions of the SyncML application entity caused by the chosen hardware and/or software solutions.
- Limitations caused by software solutions may include the limitations of the SyncML client agent, server agent or the synchronization engine.
- the size of the available memory for the SyncML application entity (CA, SA) is one important factor that can be considered.
- Implementation specific limitations may be caused by the processor CPU, SCPU itself. In mobile devices, the processor may be so slow that the SyncML application needs to limit the message size in order to avoid time-outs, i.e. in order to process received SyncML messages and to reply to them quickly enough.
- the limitations are typically caused by software solutions.
- the transport layer-specific limitations refer to transport layer-specific limitations caused by the implementation of the transport layer service in the device 1 determining the maximum SyncML message size or in some other device (device 2 ) providing transport layer services for the SyncML messages.
- the SyncML application entity (CA, SA) may request transport layer-specific limitations from the transport layer protocol entity (TTE, STE).
- the transport layer protocol entity (TTE, STE) may preferably determine the maximum message size that can be used in the transport protocol layer and inform the SyncML application entity (CA, SA) about it.
- the transport layer application entity (TTE, STE) specific limitations may limit the maximum message size. For instance, the available memory of an HTTP client can be taken into account.
- the maximum message size is then determined 303 for SyncML messages on the basis of the transport layer and/or implementation specific limitations. If there are both transport layer and implementation specific limitations for the message size, e.g. a maximum message size limit for a transport layer and a workspace memory limitation, the smallest value is chosen as the maximum message size.
- Information on the maximum message size is then transmitted 304 to the second SyncML device involved in a synchronization session with the first device. As the second device receives 305 this information, the SyncML application entity (CA, SA) is configured to compose and transmit 306 SyncML messages which are equal to or smaller than the maximum message size.
- CA SyncML application entity
- the SyncML application entity may split the data into multiple SyncML messages. If a single data item, e.g. an email message, is larger than the maximum message size, the SyncML application may try to compress it, discard a part of it or discard the whole data item.
- the maximum SyncML message size can be specified for the request-response pair (SyncML request message—SyncML response message) or for a whole SyncML session. If the device 1 includes the maximum SyncML message size only once, it advantageously means that the receiving device 2 must follow that size during the whole SyncML session. However, the device 1 can include the maximum message size in each sent message. Then the receiving device 2 must follow the value specified in last received message when it sends the next SyncML message as a response.
- the invention may, however, be implemented also to limit the message size for other types of synchronization devices, such as desktop computers.
- Device 2 in FIG. 3 may also perform the same steps as device 1 , and thus the maximum message size may be informed in both directions.
- the smaller one of the maximum messages sizes is then selected as the used maximum message size and may be used during the whole SyncML session. It is also possible to use different values, i.e. one value for SyncML messages transmitted to device 1 and another value for messages transmitted to device 2 .
- SyncML the data synchronization operations are conceptually bound into a SyncML Package.
- the SyncML Package is just a conceptual frame for one or more SyncML messages that are required to convey a set of data synchronization semantics.
- a SyncML message is a well-formed, but not necessarily valid, XML document.
- the document is identified by the SyncML root or document element type. This element type acts as a parent container (i.e. a root element type) for the SyncML message.
- the SyncML message consists of a header, specified by the SyncHdr element type, and a body, specified by the SyncBody element type:
- an element begins with a start-tag (e.g. ⁇ section>) and ends with an end-tag ( ⁇ /section>), and it can contain text or other elements.
- the SyncML header SyncHdr specifies routing and versioning information about the SyncML message.
- the SyncML body is a container for one or more SyncML Commands.
- the SyncML Commands are specified by individual element types.
- the SyncML Commands act as containers for other element types that describe the specifics of the SyncML command, including any synchronization data or meta information.
- a SyncML DTD (Document Type Definition) defines the XML document type used to represent a SyncML message.
- the DTD determines the used tags, structural proportions of the elements (!ELEMENT) between the tags, and other XML document definitions.
- SyncML messages typically refer to a DTD that is already known (it is also possible to include DTD in transferred SyncML messages).
- the maximum message size is preferably determined in a header part (SyncHdr) of a SyncML message.
- the content model of the SyncHdr element in the SyncML DTD may be defined as follows:
- ‘?’ denotes that the particular element is optional.
- ‘VerDTD’ specifies the version identifier of the SyncML representation protocol specification used to represent the SyncML message
- ‘VerProto’ specifies the version identifier of the SyncML synchronization protocol specification used with the SyncML message
- ‘SessionID’ specifies the identifier of the SyncML session associated with the SyncML message
- ‘MsgID’ specifies a SyncML session-unique identifier for the SyncML message
- ‘Target’ specifies target routing or mapping information
- ‘Source’ specifies source routing or mapping information
- ‘RespURI?’ specifies the URI that the recipient must use for any response to this message
- ‘NoResp?’ indicates that the originator does not want a response status to be sent back in the response message
- ‘Cred?’ specifies an authentication credential for the originator.
- the ‘Meta?’ element may be used to convey meta information about the SyncML messages, it may be used especially to convey information on the maximum byte size of a SyncML response.
- Annex 1 illustrates an example of the SyncHdr container element in which the maximum message size is specified.
- the SyncML synchronization protocol can be implemented utilizing various transport layer protocols, such as the HTTP protocol, the WSP protocol of the WAP standard, the OBEX protocol used for cable connections, such as USB or RS-232, for short-range radio frequency connections (Blue-tooth) or for infrared connections (IrDA), the TCP/IP stack or the transport layer service which is offered by the e-mail protocol (SMTP).
- Transfer at the lower layers can be performed according to the underlying network using e.g. short messages or other signaling type transmission methods (e.g. USSD; Unstructured Supplementary Service Data), circuit-switched data calls or packet-switched data transfer services.
- the HTTP protocol is used for providing the transport layer transmission.
- the SyncML implementation specific limitations are advantageously used to determine the maximum message size. For instance, the amount or a part of the available workspace of the SyncML application is taken as the maximum message size. It is also possible to consider transport layer limitations, such as the limitations caused by the HTTP server software or the available memory for an HTTP client.
- the OBEX protocol is used to offer the transport layer transmission.
- the maximum OBEX packet length is the transport layer specific limitation and may be taken as the maximum SyncML message size.
- a CONNECT packet is sent between the parties of the OBEX session (OBEX client and OBEX server) and it indicates the maximum size OBEX packet that the device can receive.
- the OBEX client and server may have different maximum lengths.
- OBEX link establishment reference is made to Chapters 3.3.1.3 and 3.3.1.4 on page 24 of OBEX specification “IrDA Object Exchange Protocol, IrOBEX”, version 1.2, Mar. 18, 1999, Infrared Association.
- the SyncML implementation-specific limitations may also be considered when determining the maximum message size.
- the WSP protocol is used to offer the transport layer transmission.
- the WSP layer maximum message size determines the transport layer specific limitation to the maximum SyncML message size.
- the SyncML application entity (CA, SA) requests maximum message size in a WSP session from the WSP entity (TTE and/or STE in FIG. 2 b ).
- the WSP message size may be found out using a capability negotiation mechanism.
- the capability negotiation is used for agreeing on WSP session functionality and protocol options.
- WSP session capabilities can be negotiated during the WSP session establishment. Capability negotiation allows a WSP server application to determine whether a WSP client can support certain protocol facilities and configurations.
- WAP-230-WSP Wireless Session Protocol Specification
- Chapter 6.3.2.1 “Capability Negotiation”, pages 20-22.
- SyncML client TE and server S may determine the maximum SyncML message size differently.
- OBEX-link may be used between a mobile station and a PC and a HTTP-connection may be used between the PC and a synchronization server.
- FIG. 4 is a signaling diagram illustrating a preferred embodiment in which a WAP stack is used between a TE and a WAP gateway WAP GW, and an HTTP/TCP/IP stack is used between the WAP gateway and the synchronization server S.
- the SyncML application entity CA in FIG. 2 b
- the WSP entity TTE in FIG. 2 b
- the connection is established (a WSP session to the WAP GW and an HTTP connection from the WAP GW to the SyncML server S).
- the WSP capability negotiation is used 402 , 403 to determine the maximum message size the WAP gateway is able to handle and, according to a preferred embodiment, this message size is also taken 404 as the maximum message size for SyncML messages to the TE.
- the TE may also take other limitations into account, such as the memory limitations or the client message size on the WSP layer, i.e. the maximum message size that can be sent to the client during the SyncML session.
- the TE transmits 405 a client initialization package to the server S in one or more SyncML messages (not exceeding the server maximum message size).
- the client initialization package informs the synchronization server S of the maximum message size, the databases whose data are to be synchronized, and the type of synchronization to be used.
- the client initialization package typically also includes authentication information and information on the services and device features supported by the terminal TE.
- the SyncML server S synchronizing with the terminal may not specify the maximum message size if there are no limitations from its side for the size of SyncML messages when it receives SyncML messages from the terminal.
- the server S also determines 406 the maximum message size for SyncML messages.
- the server S then sends 407 to the terminal TE a server initialization package containing typical information on SyncML session initialization and the maximum message size determined by the S.
- the TE selects 408 the maximum message size to be used during the SyncML session in both directions by selecting the smaller one of the determined ( 404 , 406 ) message sizes.
- the data of at least one database DB defined during the initialization and the data of the terminal TE can be synchronized.
- the type of the synchronization can be e.g.:
- the SyncML messages transferred 409 during the SyncML session do not exceed the maximum message size. It is possible, however, to change the message size during the session by including a new maximum message size in the transferred message. It should be noted that, unlike in FIG. 4 , already the server S may compare the maximum message sizes and select the used maximum message size.
- a minimum limit may also be specified for synchronization messages to ensure efficiency.
- the limit may be e.g. 3000 bytes. Thus, if a maximum message size under 3000 bytes is determined or requested, 3000 bytes is selected ( 408 ) as the maximum message size.
- FIG. 4 can be utilized in synchronization between more than two devices, in which case the smallest determined maximum message size is preferably used.
- synchronization can also be started without separate initialization messages. In that case initialization is performed simultaneously with synchronization, during which also the information on the maximum message size may be transferred. In that case the number of messages to be sent during synchronization can be reduced.
- the transport layer-specific limitations may also include lower layer specific limitations, e.g. taking into account the available bandwidth over a wireless connection.
- the transport layer entity (TTE, STE) may request these limitations from the lower layer protocol entities.
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The invention relates to a method of limiting the size of synchronization messages between a first synchronization device and a second synchronization device. The first device specifies a maximum message size for synchronization messages to be sent to the first device and transmits information on the maximum message size to the second device. The second device transmits to the first device one or more synchronization messages which are equal to or smaller than the maximum message size of the first device.
Description
- This application is a continuation of, claims priority to and the benefit of U.S. application Ser. No. 09/971,213, filed on 3 Oct. 2001, the disclosure of which is incorporated herein by references in its entirety.
- The invention relates to data synchronization between two or more synchronization devices, particularly to limiting the size of synchronization messages during a synchronization session. Data synchronization is an operation in which a correspondence between at least two data collections is created in such a way that after the synchronization the units of the data collections substantially correspond to each other.
- Data of portable terminals, such as portable computers, PDA (Personal Digital Assistant) devices, mobile stations or pagers, can be synchronized with network applications, desktop computer applications or other databases in a telecommunications system. Data of calendar and e-mail applications, in particular, are synchronized. Synchronization has previously been based on different proprietary protocols which are not compatible with each other. This restricts the use of terminal or data types and often causes problems to the user. In mobile communication, in particular, it is important to acquire and update data irrespective of the terminal or application used.
- The SyncML (Synchronization Markup Language), which is based on the XML (Extensible Markup Language) has been provided for improved synchronization of application data. The SyncML synchronization protocol using messages in the SyncML format (SyncML messages) allows synchronization of data in any application between any networked terminals. For example, a calendar entry in a mobile station is automatically synchronized with the network calendar used by a company secretary.
-
FIG. 1 shows an example of synchronization where a mobile station MS functions as the SyncML client terminal and a network server S functions as the SyncML server. The SyncML synchronization service comprises first initializing a synchronization session during which e.g. the database to be synchronized is selected. The SyncML client terminal MS synchronization application layer functions are provided by a synchronization client agent, which implements the SyncML protocol inter alia by sending a SyncML package (Client Modifications), which includes, in one or more SyncML messages, modifications made after the last synchronization session to the data that is the object of synchronization in the mobile station MS. The SyncML server S synchronization application layer functions are provided by a sync server agent, which controls synchronization, and a synchronization block (Sync Engine). The server usually waits for an initiative for synchronization from the SyncML client (MS). The server S synchronizes the data, i.e. analyses the changes made to the database and client terminal data, and harmonizes it (makes necessary modifications, replacements and deletions). After this, the SyncML server S sends the server modifications back to the SyncML client (MS). The example described above is simple, yet it illustrates the roles of the devices according to the SyncML standard. The SyncML client terminal (MS) is typically a mobile station (MS), a PC (Personal Computer), a laptop, or a PDA device. The SyncML server S is typically a network server or a PC. - The SyncML synchronization protocol operates in both wireless and wired networks and supports several transfer protocols. The SyncML synchronization protocol can be implemented, for example, on top of the HTTP protocol (Hyper Text Transfer Protocol), the WSP protocol (Wireless Session Protocol) of the WAP (Wireless Application Protocol) standard, the OBEX protocol used for cable links, such as the USB (Universal Serial Bus) or RS-232, or for short-range radio frequency (Bluetooth) links or infrared (IrDA) links, on top of a TCP/IP (Transport Control Protocol/Internet Protocol) stack, and also on top of an e-mail protocol (SMTP, Simple Mail Transfer Protocol). There are typically several different transmission media between the devices (MS, S) of a SyncML session, for instance a GSM network providing a wireless connection, and a local area network LAN. Also many transport layer protocols may be used to transfer SyncML messages. Different transmission media and the devices involved in the SyncML session may have different properties, e.g. varying data rates and packet sizes. The SyncML consists of end-to-end transmission of SyncML messages and it has to function even though a plurality of transport layer protocols is used. The devices are not typically aware of the message size they should use when sending synchronization messages to each other. If a device sends a large SyncML message, it is possible that the transport layer is not able to deliver it or a receiving device is not able to process it after it has arrived.
- An object of the invention is to avoid the problem described above and to provide means for limiting the size of transferred synchronization messages. The objects of the invention are achieved with a method, a synchronization system, synchronization devices, and computer program products which are characterized by what is disclosed in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.
- The invention is based on determining maximum message size for synchronization messages. A first device specifies a maximum message size for synchronization messages to be sent to the first device and transmits information on the maximum message size to a second device. The second device transmits to the first device synchronization messages that do not exceed the maximum message size.
- The arrangement of the invention has the advantage that the reliability of synchronization is improved as the problems caused by too large synchronization messages are avoided. If there is a large amount of synchronization data to be transferred, the data can be divided into multiple synchronization messages according to the capabilities of the receiving device.
- The term ‘synchronization message’ refers generally to messages composed at the application layer by a synchronization application entity and comprising synchronization-related data. The synchronization messages are sent to lower layers (transport layer) for transmission, where they are changed into transport layer packets. According to a preferred embodiment of the invention, the SyncML protocol is used. Thus the SyncML synchronization message may contain SyncML commands, as well as the related synchronization data and meta information.
- According to a preferred embodiment of the invention, the maximum messages sizes are determined in both devices of a synchronization session and the smaller value is chosen as the maximum message size for synchronization messages in both directions. This embodiment further improves the reliability of the synchronization session.
- According to another preferred embodiment of the invention, the first device is a mobile station and the second device is a synchronization server. Thus the limited resources, especially temporary memory resources, of mobile stations can be taken into account already at the synchronization application level.
- According to yet another preferred embodiment of the invention, the maximum message size is determined based on the limitations of a transport layer providing transport of the synchronization messages. This allows the limitations of intermediary devices, such as a WAP gateway, to be considered when determining the maximum message size for synchronization messages.
- The invention will be described in greater detail by means of preferred embodiments with reference to the accompanying drawings, in which
-
FIG. 1 illustrates synchronization according to the SyncML synchronization protocol; -
FIG. 2 a illustrates a wireless network and a local area network; -
FIG. 2 b illustrates a SyncML client and a SyncML server; -
FIG. 3 illustrates a method according to a preferred embodiment of the invention; and -
FIG. 4 is a signaling chart illustrating signaling events according to preferred embodiments of the invention. - In the following, the preferred embodiment of the invention will be described in a system supporting the SyncML standard, without limiting the invention thereto.
-
FIG. 2 a illustrates a networked system where data of databases DB and terminals TE can be synchronized. In respect of synchronization the terminal TE functions as a client device.FIG. 2 a shows two examples. In the first one there are terminals TE, databases DB and synchronization servers S connected to a local area network LAN. The terminal TE connected to the network LAN comprises a functionality for communicating with the devices of the network LAN, e.g. a network card and software which controls data transmission. The local area network LAN can be a local area network of any type and the TE can also communicate with the server S via the Internet, typically through a firewall FW. In the second example a terminal TE, a synchronization server S and databases DB are connected to a mobile network MNW. The terminal TE connected to the network MNW comprises a mobile station functionality for communicating wirelessly with the network MNW. The mobile network MNW can be any prior art wireless network, such as a network supporting the GSM service, a network supporting also the GPRS service (General Packet Radio Service), a third-generation mobile communication network, such as a UMTS network (Universal Mobile Telecommunications System), a wireless local area network WLAN or a private network. It should be noted that the server S can also function as a database DB, even though inFIG. 2 a the servers S and the databases DB are shown separately for the sake of clarity. Thus the term ‘database’ is to be understood broadly as referring to a data collection of any data source or data storage that can be updated by one or more applications. - As illustrated in
FIG. 2 b, the terminals TE (in wired networks LAN and in wireless networks MNW) and the servers S comprise a memory MEM; SMEM, a user interface UI; SUI, I/O means I/O; SI/O for arranging data transmission and a central processing unit CPU; SCPU, which comprises one or more processors. The memory MEM; SMEM includes a nonvolatile portion for storing applications controlling the central processor (CPU; SCPU) and a volatile memory portion for data processing. The memory MEM of the TE (which in this example is the database to be synchronized) and the memory of the databases DB store application data which are to be synchronized. A client agent CA providing the application layer functionality according to the invention is preferably implemented by executing a computer program code stored in the memory MEM in the CPU. The synchronization server S provides a synchronization agent SA and a synchronization engine SE to provide the synchronization application layer functionality. The TE and the S further comprise protocol entities providing the transport means for SyncML application layer data, especially the transport layer protocol entities TTE and STE utilizing the I/O means I/O; SI/O. The transport layer generally refers to a layer which provides the synchronization application layer with a reliable logical data transmission connection (not necessarily a protocol of the transport layer according to the OSI model, such as the TCP). The computer program code, when executed in the central processing unit CPU and the SCPU, causes the terminal TE and the synchronization server S to implement the inventive means. Embodiments of these means are illustrated inFIGS. 3 and 4 . The computer programs can be embedded or obtained via a network and/or stored in memory means, such as a floppy disk, a CD ROM or other external memory means, from which they can be loaded into the memory MEM, SMEM. It is also possible to use hardware solutions or a combination of both software and hardware solutions to implement the inventive means. -
FIG. 3 illustrates a method according to a preferred embodiment of the invention. As a need for determining the maximum message size exists 301 in a first SyncML device (either the SyncML client TE or the server S), transport layer-specific and/or SyncML implementation-specific limitations are determined 302. The need for determining the maximum message size 301 typically exists as a SyncML session is initiated, but it is possible to determine the maximum message size at any stage of the SyncML session. The term ‘synchronization session’ generally refers to the end-to-end communication between at least two synchronization protocol entities for synchronizing data between at least two devices, without being limited to the SyncML session. The SyncML implementation-specific limitations may be limitations affecting the functions of the SyncML application entity caused by the chosen hardware and/or software solutions. Limitations caused by software solutions may include the limitations of the SyncML client agent, server agent or the synchronization engine. The size of the available memory for the SyncML application entity (CA, SA) is one important factor that can be considered. Implementation specific limitations may be caused by the processor CPU, SCPU itself. In mobile devices, the processor may be so slow that the SyncML application needs to limit the message size in order to avoid time-outs, i.e. in order to process received SyncML messages and to reply to them quickly enough. In SyncML server devices, the limitations are typically caused by software solutions. - The transport layer-specific limitations refer to transport layer-specific limitations caused by the implementation of the transport layer service in the
device 1 determining the maximum SyncML message size or in some other device (device 2) providing transport layer services for the SyncML messages. The SyncML application entity (CA, SA) may request transport layer-specific limitations from the transport layer protocol entity (TTE, STE). The transport layer protocol entity (TTE, STE) may preferably determine the maximum message size that can be used in the transport protocol layer and inform the SyncML application entity (CA, SA) about it. Also the transport layer application entity (TTE, STE) specific limitations may limit the maximum message size. For instance, the available memory of an HTTP client can be taken into account. - The maximum message size is then determined 303 for SyncML messages on the basis of the transport layer and/or implementation specific limitations. If there are both transport layer and implementation specific limitations for the message size, e.g. a maximum message size limit for a transport layer and a workspace memory limitation, the smallest value is chosen as the maximum message size. Information on the maximum message size is then transmitted 304 to the second SyncML device involved in a synchronization session with the first device. As the second device receives 305 this information, the SyncML application entity (CA, SA) is configured to compose and transmit 306 SyncML messages which are equal to or smaller than the maximum message size. If the amount of synchronization-related data (SyncML package) to be sent is larger than the maximum message size, the SyncML application entity (CA, SA) may split the data into multiple SyncML messages. If a single data item, e.g. an email message, is larger than the maximum message size, the SyncML application may try to compress it, discard a part of it or discard the whole data item.
- The maximum SyncML message size can be specified for the request-response pair (SyncML request message—SyncML response message) or for a whole SyncML session. If the
device 1 includes the maximum SyncML message size only once, it advantageously means that the receivingdevice 2 must follow that size during the whole SyncML session. However, thedevice 1 can include the maximum message size in each sent message. Then the receivingdevice 2 must follow the value specified in last received message when it sends the next SyncML message as a response. - It is especially important to determine the maximum size for messages being transferred to mobile stations or other portable devices, as their processing resources are fairly limited. The invention may, however, be implemented also to limit the message size for other types of synchronization devices, such as desktop computers.
Device 2 inFIG. 3 may also perform the same steps asdevice 1, and thus the maximum message size may be informed in both directions. According to an embodiment, the smaller one of the maximum messages sizes is then selected as the used maximum message size and may be used during the whole SyncML session. It is also possible to use different values, i.e. one value for SyncML messages transmitted todevice 1 and another value for messages transmitted todevice 2. - In SyncML, the data synchronization operations are conceptually bound into a SyncML Package. The SyncML Package is just a conceptual frame for one or more SyncML messages that are required to convey a set of data synchronization semantics. A SyncML message is a well-formed, but not necessarily valid, XML document. The document is identified by the SyncML root or document element type. This element type acts as a parent container (i.e. a root element type) for the SyncML message. The SyncML message consists of a header, specified by the SyncHdr element type, and a body, specified by the SyncBody element type:
-
1 <SyncML><SyncHdr> . . . </SyncHdr><SyncBody> . . . </SyncBody></SyncML> - As is well known for the XML language, an element begins with a start-tag (e.g. <section>) and ends with an end-tag (</section>), and it can contain text or other elements. The SyncML header SyncHdr specifies routing and versioning information about the SyncML message. The SyncML body is a container for one or more SyncML Commands. The SyncML Commands are specified by individual element types. The SyncML Commands act as containers for other element types that describe the specifics of the SyncML command, including any synchronization data or meta information.
- A SyncML DTD (Document Type Definition) defines the XML document type used to represent a SyncML message. The DTD determines the used tags, structural proportions of the elements (!ELEMENT) between the tags, and other XML document definitions. SyncML messages typically refer to a DTD that is already known (it is also possible to include DTD in transferred SyncML messages). The maximum message size is preferably determined in a header part (SyncHdr) of a SyncML message. The content model of the SyncHdr element in the SyncML DTD may be defined as follows:
-
<!ELEMENT SyncHdr (VerDTD, VerProto, SessionID, MsgID, Target, Source, RespURI?, NoResp?, Cred?, Meta?)> - The question mark ‘?’ denotes that the particular element is optional. ‘VerDTD’ specifies the version identifier of the SyncML representation protocol specification used to represent the SyncML message, ‘VerProto’ specifies the version identifier of the SyncML synchronization protocol specification used with the SyncML message, ‘SessionID’ specifies the identifier of the SyncML session associated with the SyncML message, ‘MsgID’ specifies a SyncML session-unique identifier for the SyncML message, ‘Target’ specifies target routing or mapping information, ‘Source’ specifies source routing or mapping information, ‘RespURI?’ specifies the URI that the recipient must use for any response to this message, ‘NoResp?’ indicates that the originator does not want a response status to be sent back in the response message and ‘Cred?’ specifies an authentication credential for the originator. The ‘Meta?’ element may be used to convey meta information about the SyncML messages, it may be used especially to convey information on the maximum byte size of a SyncML response.
Annex 1 illustrates an example of the SyncHdr container element in which the maximum message size is specified. - The SyncML synchronization protocol can be implemented utilizing various transport layer protocols, such as the HTTP protocol, the WSP protocol of the WAP standard, the OBEX protocol used for cable connections, such as USB or RS-232, for short-range radio frequency connections (Blue-tooth) or for infrared connections (IrDA), the TCP/IP stack or the transport layer service which is offered by the e-mail protocol (SMTP). Transfer at the lower layers can be performed according to the underlying network using e.g. short messages or other signaling type transmission methods (e.g. USSD; Unstructured Supplementary Service Data), circuit-switched data calls or packet-switched data transfer services.
- According to an embodiment, the HTTP protocol is used for providing the transport layer transmission. In this embodiment the SyncML implementation specific limitations are advantageously used to determine the maximum message size. For instance, the amount or a part of the available workspace of the SyncML application is taken as the maximum message size. It is also possible to consider transport layer limitations, such as the limitations caused by the HTTP server software or the available memory for an HTTP client.
- According to another embodiment, the OBEX protocol is used to offer the transport layer transmission. In this embodiment, the maximum OBEX packet length is the transport layer specific limitation and may be taken as the maximum SyncML message size. During OBEX link establishment, a CONNECT packet is sent between the parties of the OBEX session (OBEX client and OBEX server) and it indicates the maximum size OBEX packet that the device can receive. The OBEX client and server may have different maximum lengths. For a more detailed description of the OBEX link establishment, reference is made to Chapters 3.3.1.3 and 3.3.1.4 on page 24 of OBEX specification “IrDA Object Exchange Protocol, IrOBEX”, version 1.2, Mar. 18, 1999, Infrared Association. The SyncML implementation-specific limitations may also be considered when determining the maximum message size.
- According to yet another embodiment, the WSP protocol is used to offer the transport layer transmission. In this embodiment the WSP layer maximum message size determines the transport layer specific limitation to the maximum SyncML message size. The SyncML application entity (CA, SA) requests maximum message size in a WSP session from the WSP entity (TTE and/or STE in
FIG. 2 b). The WSP message size may be found out using a capability negotiation mechanism. The capability negotiation is used for agreeing on WSP session functionality and protocol options. WSP session capabilities can be negotiated during the WSP session establishment. Capability negotiation allows a WSP server application to determine whether a WSP client can support certain protocol facilities and configurations. For a more detailed description of the WSP capability negotiation, reference is made to WAP specification WAP-230-WSP “Wireless Session Protocol Specification”, July 2001, Chapter 6.3.2.1, “Capability Negotiation”, pages 20-22. - It should be noted that more than one transport protocols can be used in communication between the SyncML client TE and server S and that thus the server and the client may determine the maximum SyncML message size differently. For instance, an OBEX-link may be used between a mobile station and a PC and a HTTP-connection may be used between the PC and a synchronization server.
-
FIG. 4 is a signaling diagram illustrating a preferred embodiment in which a WAP stack is used between a TE and a WAP gateway WAP GW, and an HTTP/TCP/IP stack is used between the WAP gateway and the synchronization server S. When there is aneed 401 in the TE to synchronize data of the databases (e.g. MEM, DB), the SyncML application entity (CA inFIG. 2 b) requests the maximum message size from the WSP entity (TTE inFIG. 2 b) and to activate a transport layer connection to the WAP gateway WAP GW and further to the SyncML server. The connection is established (a WSP session to the WAP GW and an HTTP connection from the WAP GW to the SyncML server S). The WSP capability negotiation is used 402, 403 to determine the maximum message size the WAP gateway is able to handle and, according to a preferred embodiment, this message size is also taken 404 as the maximum message size for SyncML messages to the TE. The TE may also take other limitations into account, such as the memory limitations or the client message size on the WSP layer, i.e. the maximum message size that can be sent to the client during the SyncML session. - As the transport layer connection is established between the server S and the TE, the TE transmits 405 a client initialization package to the server S in one or more SyncML messages (not exceeding the server maximum message size). The client initialization package informs the synchronization server S of the maximum message size, the databases whose data are to be synchronized, and the type of synchronization to be used. The client initialization package typically also includes authentication information and information on the services and device features supported by the terminal TE.
- When the terminal TE has specified the maximum SyncML message size, the SyncML server S synchronizing with the terminal may not specify the maximum message size if there are no limitations from its side for the size of SyncML messages when it receives SyncML messages from the terminal. In this embodiment, the server S also determines 406 the maximum message size for SyncML messages. The server S then sends 407 to the terminal TE a server initialization package containing typical information on SyncML session initialization and the maximum message size determined by the S. The TE selects 408 the maximum message size to be used during the SyncML session in both directions by selecting the smaller one of the determined (404, 406) message sizes.
- After the initialization has been finished, the data of at least one database DB defined during the initialization and the data of the terminal TE can be synchronized. The type of the synchronization can be e.g.:
- Two-way sync
One-way sync from client only
Refresh sync from client only
One-way sync from server only
Refresh sync from server only
Server alerted sync. - The SyncML messages transferred 409 during the SyncML session do not exceed the maximum message size. It is possible, however, to change the message size during the session by including a new maximum message size in the transferred message. It should be noted that, unlike in
FIG. 4 , already the server S may compare the maximum message sizes and select the used maximum message size. - According to an embodiment, a minimum limit may also be specified for synchronization messages to ensure efficiency. The limit may be e.g. 3000 bytes. Thus, if a maximum message size under 3000 bytes is determined or requested, 3000 bytes is selected (408) as the maximum message size.
- It should be noted that the functions illustrated in
FIG. 4 can be utilized in synchronization between more than two devices, in which case the smallest determined maximum message size is preferably used. Unlike inFIG. 4 , synchronization can also be started without separate initialization messages. In that case initialization is performed simultaneously with synchronization, during which also the information on the maximum message size may be transferred. In that case the number of messages to be sent during synchronization can be reduced. - In addition to the description above, the transport layer-specific limitations may also include lower layer specific limitations, e.g. taking into account the available bandwidth over a wireless connection. The transport layer entity (TTE, STE) may request these limitations from the lower layer protocol entities.
- It will be obvious to a person skilled in the art that as the technology advances, the inventive concept can be implemented in a number of ways. The invention and its embodiments are thus not limited to the examples described above but may vary within the scope of the claims.
-
ANNEX 1<SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>1</SessionID> <MsgID>1</MsgID> <Target><LocURI>http://www.sync-server.com</LocURI> </Target> <Source><LocURI>IMEI:123456789012345</LocURI></Source> <Meta> <!--The Meta is now used to indicate the maximum SyncML message size, which a terminal can receive.--> <MaxMsgSize xmlns = ‘syncml:metinf’>5000</MaxMsgSize> </Meta> </SyncHdr>
Claims (28)
1. A method, comprising:
specifying, in a first device, a maximum message size for synchronization messages, complying with a syncml standard, associated with the first device, transmitting information related to the maximum message size from the first device to a second device, and
receiving at the first device one or more synchronization messages with a size equal to or smaller than the maximum message size specified in the first device, wherein the first device is functioning as a syncml client and the second device is functioning as a syncml server, or the first device is functioning as a syncml server and the second device is functioning as a syncml client.
2. A method as claimed in claim 1 , further comprising:
receiving at the first device a maximum message size for synchronization messages associated with the second device, and transmitting to the second device synchronization messages with a size equal to or smaller than the received maximum message size for synchronization messages associated with the second device.
3. A method as claimed in claim 1 , wherein
a maximum message size for synchronization messages associated with the second device is received at the first device,
the maximum message sizes for the first device and the second device are compared,
the smaller one of the maximum message sizes is selected for a synchronization session between the first device and the second device, and synchronization messages which are equal to or smaller than the selected message size are exchanged between the first device and the second device.
4. A method as claimed in claim 1 , wherein the information related to the maximum message size is transmitted during synchronization session initialization in an initialization message.
5. A method as claimed in claim 1 , wherein the maximum message size is specified based on implementation specific limitations of the first device affecting functionality of the synchronization application entity of the first device.
6. A method as claimed in claim 1 , wherein the maximum message size is specified based on limitations of a transport layer providing transport of the synchronization messages.
7. A method as claimed in claim 6 , wherein the transport layer is based on a wireless application protocol between the first device and a wireless application protocol gateway, and the maximum message size is determined based on the maximum message size the wireless application protocol gateway is capable of transferring.
8. An apparatus, comprising:
a processor configured to cause apparatus to
establish a synchronization session with a synchronization device,
specify a maximum message size for synchronization messages complying with a syncml standard associated with said apparatus device, and
transmit information related to the maximum message size to the synchronization device,
wherein, said apparatus is configured to function as a synchml client or syncml server
9. An apparatus as claimed in claim 9 , wherein the processor is configured to specify the maximum message size on the basis of implementation specific limitations of the apparatus affecting the functionality of synchronization application entity of the apparatus.
10. An apparatus as claimed in claim 9 , wherein the processor is configured to specify the maximum message size on the basis of limitations of a transport layer providing transport of the synchronization messages.
11. A synchronization device comprising:
means for functioning as a syncml client or a syncml server,
means for establishing a synchronization session with another synchronization device,
means for receiving information related to a maximum message size for synchronization messages, complying with a syncml standard, associated with the other device, and
means for transmitting to the other device synchronization messages with size equal to or smaller than the maximum message size.
12. A computer program product, embedded in a computer readable medium, comprising:
computer code configured to cause apparatus to establish a synchronization session between a first synchronization device and a second synchronization device,
computer code configured to cause apparatus to specify a maximum message size for synchronization messages complying with a syncml standard, associated with said first synchronization device, and
computer code configured to cause apparatus to transmit information related to the maximum message size to the second synchronization device, wherein the first synchronization device is functioning as a syncml client and the second synchronization device is functioning as a syncml server, or the first synchronization device is functioning as the syncml server and the other synchronization device is functioning as the syncml client.
13. A computer program product, embedded in a computer readable medium, comprising:
computer code configured to cause apparatus to establish a synchronization session between a first synchronization device and a second synchronization device,
computer code configured to cause apparatus to receive information related to a maximum message size for synchronization messages, complying with a syncml standard, associated with the second synchronization device, and
computer code configured to cause apparatus to transmit to the second synchronization device synchronization messages, complying with syncml standard, with size equal to or smaller than the maximum message size, wherein the first synchronization device is functioning as a syncml client and the second synchronization device is functioning as a syncml server, or the first synchronization device is functioning as the syncml server and the second synchronization device is functioning as the syncml client.
14. A synchronization system comprising a first synchronization device and a second synchronization device, wherein
the first device is configured to specify a maximum message size for synchronization messages to be sent to the first device and the second device is configured to determine a maximum message size for synchronization messages to be sent to the second device,
the first device is configured to transmit to the second device information related to the maximum message size for synchronization messages to be sent the first device, and
the second device is configured to compare the maximum message sizes for the first device and the second device,
the second device is configured to select the smaller size among the maximum message sizes,
the second device is configured to inform the first device of the selected maximum message size, and
the first device and the second device are configured to transmit synchronization messages which are equal to or smaller than the selected message size.
15. A method according to claim 1 , wherein the information related to the maximum message size is indicated in a meta element of a synchronization message header.
16. An apparatus as claimed in claim 9 , wherein the processor is configured to transmit the information related to the maximum message size, during synchronization session initialization, in an initialization message.
17. An apparatus as claimed in claim 9 , wherein the processor is configured to indicate the information related to the maximum message size in a meta element of a synchronization message header.
18. A computer program product according to claim 13 , the computer program product comprising code for transmitting the information related to the maximum message size, during synchronization session initialization, in an initialization message.
19. A computer program product according to claim 13 , the computer program product comprising code for indicating the information related to the maximum message size in a meta element of a synchronization message header.
20. A computer program product according to claim 14 , the computer program product comprising code for receiving the information related to the maximum message size, during synchronization session initialization, in an initialization message.
21. A computer program product according to claim 14 , the computer program product comprising code for receiving the information related to the maximum message size in a meta element of a synchronization message header.
22. An apparatus comprising:
means for establishing a synchronization session with a synchronization device,
means for specifying a maximum message size for synchronization messages, complying with a synchml standard, associated with the synchronization device, and
means for transmitting information related to the maximum message size to the synchronization device, wherein the apparatus is configured to function as a syncml client or syncml server.
23. An apparatus, comprising:
a processor configured to cause apparatus to
receive information related to a maximum message size for synchronization messages, complying with a syncml standard, associated with a synchronization device, and
transmit to the synchronization device synchronization messages, complying with the synchml standard, with a size equal to or smaller than the maximum message size,
wherein the apparatus is configured to function as a syncml client or a syncml server.
24. The apparatus as claimed in claim 24 , wherein the processor is configured to receive the information related to the maximum message size, during synchronization session initialization, in an initialization message.
25. The apparatus as claimed in claim 24 , wherein the processor is configured to receive the information related to the maximum message size in a meta element of a synchronization message header.
26. A method comprising:
receiving, at a first synchronization device, information related to a maximum message size for synchronization messages, complying with a syncml standard, associated with a second synchronization device; and
transmitting to the second synchronization device synchronization messages, complying with the synchml standard, with a size equal to or smaller than the maximum message size,
wherein the first synchronization device is functioning as a syncml client and the second synchronization device is functioning as a syncml server, or the first synchronization device is functioning as a syncml server and the second synchronization device is functioning as a syncml client.
27. The method as claimed in claim 27 , wherein the information related to the maximum message size is received, during synchronization session initialization, in an initialization message.
28. The method as claimed in claim 27 , wherein the information related to the maximum message size is received in a meta element of a synchronization message header.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/503,996 US20100017520A1 (en) | 2001-10-03 | 2009-07-16 | Data synchronization |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/971,213 US7570668B2 (en) | 2001-10-03 | 2001-10-03 | Data synchronization |
US12/503,996 US20100017520A1 (en) | 2001-10-03 | 2009-07-16 | Data synchronization |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/971,213 Continuation US7570668B2 (en) | 2001-10-03 | 2001-10-03 | Data synchronization |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100017520A1 true US20100017520A1 (en) | 2010-01-21 |
Family
ID=25518077
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/971,213 Active 2026-03-28 US7570668B2 (en) | 2001-10-03 | 2001-10-03 | Data synchronization |
US12/503,996 Abandoned US20100017520A1 (en) | 2001-10-03 | 2009-07-16 | Data synchronization |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/971,213 Active 2026-03-28 US7570668B2 (en) | 2001-10-03 | 2001-10-03 | Data synchronization |
Country Status (1)
Country | Link |
---|---|
US (2) | US7570668B2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100030846A1 (en) * | 2006-07-28 | 2010-02-04 | Gemalto Sa | Method of synchronization between a mobile equipment unit and a smart card |
CN102684865A (en) * | 2011-03-07 | 2012-09-19 | 中国移动通信有限公司 | Method, system and device for data synchronization |
US20120278492A1 (en) * | 2008-12-24 | 2012-11-01 | Juniper Networks, Inc. | Using a server's capability profile to establish a connection |
Families Citing this family (134)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
US8364136B2 (en) | 1999-02-01 | 2013-01-29 | Steven M Hoffberg | Mobile system, a method of operating mobile system and a non-transitory computer readable medium for a programmable control of a mobile system |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
US7409685B2 (en) | 2002-04-12 | 2008-08-05 | Hewlett-Packard Development Company, L.P. | Initialization and update of software and/or firmware in electronic devices |
US8479189B2 (en) | 2000-11-17 | 2013-07-02 | Hewlett-Packard Development Company, L.P. | Pattern detection preprocessor in an electronic device update generation system |
US6760772B2 (en) | 2000-12-15 | 2004-07-06 | Qualcomm, Inc. | Generating and implementing a communication protocol and interface for high data rate signal transfer |
US20040024910A1 (en) * | 2001-06-01 | 2004-02-05 | Marl Coyle B. | Adaptive synchronization of service data |
US20030045311A1 (en) * | 2001-08-30 | 2003-03-06 | Tapani Larikka | Message transfer from a source device via a mobile terminal device to a third device and data synchronization between terminal devices |
US8812706B1 (en) | 2001-09-06 | 2014-08-19 | Qualcomm Incorporated | Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system |
US7570668B2 (en) * | 2001-10-03 | 2009-08-04 | Nokia Corporation | Data synchronization |
US7356098B2 (en) | 2001-11-14 | 2008-04-08 | Ipwireless, Inc. | Method, communication system and communication unit for synchronisation for multi-rate communication |
US8130953B2 (en) * | 2002-03-08 | 2012-03-06 | Sony Ericsson Mobile Communications Ab | Security protection for data communication |
US8290505B2 (en) | 2006-08-29 | 2012-10-16 | Telecommunications Systems, Inc. | Consequential location derived information |
US7426380B2 (en) | 2002-03-28 | 2008-09-16 | Telecommunication Systems, Inc. | Location derived presence information |
US8918073B2 (en) | 2002-03-28 | 2014-12-23 | Telecommunication Systems, Inc. | Wireless telecommunications location based services scheme selection |
US9154906B2 (en) | 2002-03-28 | 2015-10-06 | Telecommunication Systems, Inc. | Area watcher for wireless network |
US8027697B2 (en) | 2007-09-28 | 2011-09-27 | Telecommunication Systems, Inc. | Public safety access point (PSAP) selection for E911 wireless callers in a GSM type system |
US8126889B2 (en) | 2002-03-28 | 2012-02-28 | Telecommunication Systems, Inc. | Location fidelity adjustment based on mobile subscriber privacy profile |
US6721871B2 (en) * | 2002-04-02 | 2004-04-13 | Nokia Corporation | Method and apparatus for synchronizing data stores with respect to changes in folders |
US20040003007A1 (en) * | 2002-06-28 | 2004-01-01 | Prall John M. | Windows management instrument synchronized repository provider |
FI114948B (en) * | 2002-09-20 | 2005-01-31 | Nokia Corp | Instructions for control objects |
WO2004038546A2 (en) * | 2002-10-21 | 2004-05-06 | Bitfone Corporation | System with required enhancements to syncml dm environment to support firmware updates |
US8666397B2 (en) | 2002-12-13 | 2014-03-04 | Telecommunication Systems, Inc. | Area event handling when current network does not cover target area |
KR100521033B1 (en) * | 2003-05-21 | 2005-10-11 | 엘지전자 주식회사 | Method for relay forwarding the message |
CN103220282B (en) | 2003-06-02 | 2016-05-25 | 高通股份有限公司 | Generate and implement one for more signal protocol and the interface of High Data Rate |
RU2006107561A (en) * | 2003-08-13 | 2007-09-20 | Квэлкомм Инкорпорейтед (US) | SIGNAL INTERFACE FOR HIGH DATA TRANSMISSION SPEEDS |
DE602004019797D1 (en) | 2003-09-10 | 2009-04-16 | Qualcomm Inc | INTERFACE FOR HIGH DATA RATE |
US8555273B1 (en) | 2003-09-17 | 2013-10-08 | Palm. Inc. | Network for updating electronic devices |
US7293064B1 (en) * | 2003-10-01 | 2007-11-06 | Sprint Spectrum L.P. | Method and system for dynamic variation of orginal message length in a reply message |
AU2004306903C1 (en) | 2003-10-15 | 2009-01-22 | Qualcomm Incorporated | High data rate interface |
CA2544030A1 (en) | 2003-10-29 | 2005-05-12 | Qualcomm Incorporated | High data rate interface |
US20070180127A1 (en) * | 2003-11-11 | 2007-08-02 | Nokia Corporation | Preconfigured syncml profile categories |
EP2247066B1 (en) | 2003-11-12 | 2012-09-26 | Qualcomm Incorporated | High data rate interface with improved link control |
WO2005053272A1 (en) | 2003-11-25 | 2005-06-09 | Qualcomm Incorporated | High data rate interface with improved link synchronization |
US7424293B2 (en) | 2003-12-02 | 2008-09-09 | Telecommunication Systems, Inc. | User plane location based service using message tunneling to support roaming |
KR100906319B1 (en) | 2003-12-08 | 2009-07-06 | 퀄컴 인코포레이티드 | High data rate interface with link synchronization |
US7260186B2 (en) | 2004-03-23 | 2007-08-21 | Telecommunication Systems, Inc. | Solutions for voice over internet protocol (VoIP) 911 location services |
US20080090546A1 (en) | 2006-10-17 | 2008-04-17 | Richard Dickinson | Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging |
US20080126535A1 (en) | 2006-11-28 | 2008-05-29 | Yinjun Zhu | User plane location services over session initiation protocol (SIP) |
BRPI0508582A (en) | 2004-03-10 | 2007-08-14 | Qualcomm Inc | High data rate interface equipment and method |
FI20045077A (en) * | 2004-03-16 | 2005-09-17 | Nokia Corp | Method and apparatus for indicating size restriction of message |
KR20060130749A (en) | 2004-03-17 | 2006-12-19 | 퀄컴 인코포레이티드 | High data rate interface apparatus and method |
CA2560744C (en) | 2004-03-24 | 2012-12-04 | Qualcomm Incorporated | High data rate interface apparatus and method |
US7904895B1 (en) | 2004-04-21 | 2011-03-08 | Hewlett-Packard Develpment Company, L.P. | Firmware update in electronic devices employing update agent in a flash memory card |
US7623551B2 (en) * | 2004-05-20 | 2009-11-24 | International Business Machines Corporation | Method, system and program product for synchronizing data elements between devices |
EP1978692B1 (en) | 2004-06-04 | 2011-07-27 | QUALCOMM Incorporated | High data rate interface apparatus and method |
US8650304B2 (en) | 2004-06-04 | 2014-02-11 | Qualcomm Incorporated | Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system |
US20060047837A1 (en) * | 2004-06-14 | 2006-03-02 | Jukka-Pekka Rissanen | Arrangement for informing application capabilities by an object exchange protocol |
US20060047756A1 (en) * | 2004-06-16 | 2006-03-02 | Jussi Piispanen | Method and apparatus for indicating truncated email information in email synchronization |
US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
US20060080354A1 (en) * | 2004-08-27 | 2006-04-13 | Nokia Corporation | System for selecting data from a data store based on utility of the data |
US7629926B2 (en) | 2004-10-15 | 2009-12-08 | Telecommunication Systems, Inc. | Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas |
US6985105B1 (en) | 2004-10-15 | 2006-01-10 | Telecommunication Systems, Inc. | Culled satellite ephemeris information based on limiting a span of an inverted cone for locating satellite in-range determinations |
US8667363B2 (en) * | 2004-11-24 | 2014-03-04 | Qualcomm Incorporated | Systems and methods for implementing cyclic redundancy checks |
US8699330B2 (en) | 2004-11-24 | 2014-04-15 | Qualcomm Incorporated | Systems and methods for digital data transmission rate control |
US8723705B2 (en) | 2004-11-24 | 2014-05-13 | Qualcomm Incorporated | Low output skew double data rate serial encoder |
US8539119B2 (en) * | 2004-11-24 | 2013-09-17 | Qualcomm Incorporated | Methods and apparatus for exchanging messages having a digital data interface device message format |
US8692838B2 (en) * | 2004-11-24 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
US8873584B2 (en) | 2004-11-24 | 2014-10-28 | Qualcomm Incorporated | Digital data interface device |
US20060161691A1 (en) * | 2004-11-24 | 2006-07-20 | Behnam Katibian | Methods and systems for synchronous execution of commands across a communication link |
US7353034B2 (en) | 2005-04-04 | 2008-04-01 | X One, Inc. | Location sharing and tracking using mobile phones or other wireless devices |
WO2006111017A1 (en) * | 2005-04-18 | 2006-10-26 | Research In Motion Limited | System and method of synchronization of internal data cache with wireless device application data repositories |
US7657574B2 (en) * | 2005-06-03 | 2010-02-02 | Microsoft Corporation | Persistent storage file change tracking |
US20070014277A1 (en) * | 2005-07-14 | 2007-01-18 | Yahoo! Inc. | Content router repository |
US7623515B2 (en) * | 2005-07-14 | 2009-11-24 | Yahoo! Inc. | Content router notification |
US7631045B2 (en) * | 2005-07-14 | 2009-12-08 | Yahoo! Inc. | Content router asynchronous exchange |
US20070038703A1 (en) * | 2005-07-14 | 2007-02-15 | Yahoo! Inc. | Content router gateway |
US20070016636A1 (en) * | 2005-07-14 | 2007-01-18 | Yahoo! Inc. | Methods and systems for data transfer and notification mechanisms |
US20070014307A1 (en) * | 2005-07-14 | 2007-01-18 | Yahoo! Inc. | Content router forwarding |
US7849199B2 (en) * | 2005-07-14 | 2010-12-07 | Yahoo ! Inc. | Content router |
US8660573B2 (en) | 2005-07-19 | 2014-02-25 | Telecommunications Systems, Inc. | Location service requests throttling |
US9282451B2 (en) | 2005-09-26 | 2016-03-08 | Telecommunication Systems, Inc. | Automatic location identification (ALI) service requests steering, connection sharing and protocol translation |
US7825780B2 (en) | 2005-10-05 | 2010-11-02 | Telecommunication Systems, Inc. | Cellular augmented vehicle alarm notification together with location services for position of an alarming vehicle |
US7907551B2 (en) | 2005-10-06 | 2011-03-15 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) location based 911 conferencing |
US8467320B2 (en) | 2005-10-06 | 2013-06-18 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) multi-user conferencing |
US8024290B2 (en) | 2005-11-14 | 2011-09-20 | Yahoo! Inc. | Data synchronization and device handling |
US8065680B2 (en) * | 2005-11-15 | 2011-11-22 | Yahoo! Inc. | Data gateway for jobs management based on a persistent job table and a server table |
US8730069B2 (en) | 2005-11-23 | 2014-05-20 | Qualcomm Incorporated | Double data rate serial encoder |
US8692839B2 (en) | 2005-11-23 | 2014-04-08 | Qualcomm Incorporated | Methods and systems for updating a buffer |
US9367832B2 (en) * | 2006-01-04 | 2016-06-14 | Yahoo! Inc. | Synchronizing image data among applications and devices |
US8150363B2 (en) | 2006-02-16 | 2012-04-03 | Telecommunication Systems, Inc. | Enhanced E911 network access for call centers |
US8059789B2 (en) | 2006-02-24 | 2011-11-15 | Telecommunication Systems, Inc. | Automatic location identification (ALI) emergency services pseudo key (ESPK) |
US7899450B2 (en) | 2006-03-01 | 2011-03-01 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detection using local mobile network within cellular network |
US7471236B1 (en) | 2006-03-01 | 2008-12-30 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detector |
US9167553B2 (en) | 2006-03-01 | 2015-10-20 | Telecommunication Systems, Inc. | GeoNexus proximity detector network |
CN101047707A (en) * | 2006-03-30 | 2007-10-03 | 华为技术有限公司 | Method and system for initiating equipment ability information consultation |
US8208605B2 (en) | 2006-05-04 | 2012-06-26 | Telecommunication Systems, Inc. | Extended efficient usage of emergency services keys |
US7509350B2 (en) * | 2006-06-01 | 2009-03-24 | Research In Motion Limited | Method and apparatus for synchronizing of databases |
US8209676B2 (en) | 2006-06-08 | 2012-06-26 | Hewlett-Packard Development Company, L.P. | Device management in a network |
WO2008014454A2 (en) | 2006-07-27 | 2008-01-31 | Hewlett-Packard Development Company, L.P. | User experience and dependency management in a mobile device |
US20080034008A1 (en) * | 2006-08-03 | 2008-02-07 | Yahoo! Inc. | User side database |
US7966013B2 (en) | 2006-11-03 | 2011-06-21 | Telecommunication Systems, Inc. | Roaming gateway enabling location based services (LBS) roaming for user plane in CDMA networks without requiring use of a mobile positioning center (MPC) |
CA2578472C (en) * | 2007-01-12 | 2013-01-15 | Truecontext Corporation | Methods and system for orchestrating services and data sharing on mobile devices |
US7715444B2 (en) * | 2007-02-02 | 2010-05-11 | Palm, Inc | Resuming a previously interrupted peer-to-peer synchronization operation |
US8050386B2 (en) | 2007-02-12 | 2011-11-01 | Telecommunication Systems, Inc. | Mobile automatic location identification (ALI) for first responders |
US20080270629A1 (en) * | 2007-04-27 | 2008-10-30 | Yahoo! Inc. | Data snychronization and device handling using sequence numbers |
EP2196014A4 (en) | 2007-09-17 | 2014-12-24 | Telecomm Systems Inc | Emergency 911 data messaging |
US20090112915A1 (en) * | 2007-10-31 | 2009-04-30 | Microsoft Corporation | Class configuration for locally cached remote data binding |
US7929530B2 (en) | 2007-11-30 | 2011-04-19 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
US9130963B2 (en) | 2011-04-06 | 2015-09-08 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
JP4810544B2 (en) * | 2008-01-11 | 2011-11-09 | シャープ株式会社 | COMMUNICATION DEVICE, COMMUNICATION METHOD, COMMUNICATION PROGRAM, AND RECORDING MEDIUM |
CN101516131B (en) * | 2008-02-18 | 2012-04-04 | 华为技术有限公司 | Method, system and device for data synchronization |
US8068587B2 (en) | 2008-08-22 | 2011-11-29 | Telecommunication Systems, Inc. | Nationwide table routing of voice over internet protocol (VOIP) emergency calls |
US8892128B2 (en) | 2008-10-14 | 2014-11-18 | Telecommunication Systems, Inc. | Location based geo-reminders |
US8525681B2 (en) | 2008-10-14 | 2013-09-03 | Telecommunication Systems, Inc. | Location based proximity alert |
US20100268784A1 (en) * | 2009-04-17 | 2010-10-21 | Marc Henness | Data synchronization system and method |
US9301191B2 (en) | 2013-09-20 | 2016-03-29 | Telecommunication Systems, Inc. | Quality of service to over the top applications used with VPN |
US8867485B2 (en) | 2009-05-05 | 2014-10-21 | Telecommunication Systems, Inc. | Multiple location retrieval function (LRF) network having location continuity |
WO2012005769A1 (en) | 2010-07-09 | 2012-01-12 | Telecommunication Systems, Inc. | Location privacy selector |
US8336664B2 (en) | 2010-07-09 | 2012-12-25 | Telecommunication Systems, Inc. | Telematics basic mobile device safety interlock |
US8688087B2 (en) | 2010-12-17 | 2014-04-01 | Telecommunication Systems, Inc. | N-dimensional affinity confluencer |
US8942743B2 (en) | 2010-12-17 | 2015-01-27 | Telecommunication Systems, Inc. | iALERT enhanced alert manager |
WO2012141762A1 (en) | 2011-02-25 | 2012-10-18 | Telecommunication Systems, Inc. | Mobile internet protocol (ip) location |
US9113500B2 (en) | 2011-07-10 | 2015-08-18 | Qualcomm Incorporated | Device and method for communication of management information in ad-hoc wireless networks |
US8649806B2 (en) | 2011-09-02 | 2014-02-11 | Telecommunication Systems, Inc. | Aggregate location dynometer (ALD) |
US9479344B2 (en) | 2011-09-16 | 2016-10-25 | Telecommunication Systems, Inc. | Anonymous voice conversation |
US8831556B2 (en) | 2011-09-30 | 2014-09-09 | Telecommunication Systems, Inc. | Unique global identifier header for minimizing prank emergency 911 calls |
US9313637B2 (en) | 2011-12-05 | 2016-04-12 | Telecommunication Systems, Inc. | Wireless emergency caller profile data delivery over a legacy interface |
US9264537B2 (en) | 2011-12-05 | 2016-02-16 | Telecommunication Systems, Inc. | Special emergency call treatment based on the caller |
US8984591B2 (en) | 2011-12-16 | 2015-03-17 | Telecommunications Systems, Inc. | Authentication via motion of wireless device movement |
US9384339B2 (en) | 2012-01-13 | 2016-07-05 | Telecommunication Systems, Inc. | Authenticating cloud computing enabling secure services |
US8688174B2 (en) | 2012-03-13 | 2014-04-01 | Telecommunication Systems, Inc. | Integrated, detachable ear bud device for a wireless phone |
US9307372B2 (en) | 2012-03-26 | 2016-04-05 | Telecommunication Systems, Inc. | No responders online |
US9544260B2 (en) | 2012-03-26 | 2017-01-10 | Telecommunication Systems, Inc. | Rapid assignment dynamic ownership queue |
US9338153B2 (en) | 2012-04-11 | 2016-05-10 | Telecommunication Systems, Inc. | Secure distribution of non-privileged authentication credentials |
US9313638B2 (en) | 2012-08-15 | 2016-04-12 | Telecommunication Systems, Inc. | Device independent caller data access for emergency calls |
US9208346B2 (en) | 2012-09-05 | 2015-12-08 | Telecommunication Systems, Inc. | Persona-notitia intellection codifier |
US9456301B2 (en) | 2012-12-11 | 2016-09-27 | Telecommunication Systems, Inc. | Efficient prisoner tracking |
US8983047B2 (en) | 2013-03-20 | 2015-03-17 | Telecommunication Systems, Inc. | Index of suspicion determination for communications request |
IN2013MU01237A (en) * | 2013-03-28 | 2015-04-10 | Tata Consultancy Services Ltd | |
US9408034B2 (en) | 2013-09-09 | 2016-08-02 | Telecommunication Systems, Inc. | Extended area event for network based proximity discovery |
US9516104B2 (en) | 2013-09-11 | 2016-12-06 | Telecommunication Systems, Inc. | Intelligent load balancer enhanced routing |
US9479897B2 (en) | 2013-10-03 | 2016-10-25 | Telecommunication Systems, Inc. | SUPL-WiFi access point controller location based services for WiFi enabled mobile devices |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7570668B2 (en) * | 2001-10-03 | 2009-08-04 | Nokia Corporation | Data synchronization |
US20100077024A1 (en) * | 2007-02-16 | 2010-03-25 | Point-I Co., Ltd. | Method for transmitting data transmitted incompletely between server and client |
US20100287253A1 (en) * | 2008-01-21 | 2010-11-11 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for data synchronization |
US20110016087A1 (en) * | 2007-01-07 | 2011-01-20 | Freedman Gordon J | Synchronization methods and systems |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5379296A (en) * | 1992-12-31 | 1995-01-03 | Unisys Corporation | Method and apparatus for interfacing a workstation to a plurality of computer platforms |
US6564267B1 (en) * | 1999-11-22 | 2003-05-13 | Intel Corporation | Network adapter with large frame transfer emulation |
US6985719B2 (en) * | 2000-12-21 | 2006-01-10 | Nokia, Inc. | Secure wireless backup mechanism |
US6839564B2 (en) * | 2001-04-25 | 2005-01-04 | Nokia Corporation | Synchronization of database data |
AU2002320579B2 (en) * | 2001-07-18 | 2006-08-24 | Amplify Education, Inc. | System and method for real-time observation assessment |
US20030045311A1 (en) * | 2001-08-30 | 2003-03-06 | Tapani Larikka | Message transfer from a source device via a mobile terminal device to a third device and data synchronization between terminal devices |
US7155521B2 (en) * | 2001-10-09 | 2006-12-26 | Nokia Corporation | Starting a session in a synchronization system |
-
2001
- 2001-10-03 US US09/971,213 patent/US7570668B2/en active Active
-
2009
- 2009-07-16 US US12/503,996 patent/US20100017520A1/en not_active Abandoned
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7570668B2 (en) * | 2001-10-03 | 2009-08-04 | Nokia Corporation | Data synchronization |
US20110016087A1 (en) * | 2007-01-07 | 2011-01-20 | Freedman Gordon J | Synchronization methods and systems |
US20100077024A1 (en) * | 2007-02-16 | 2010-03-25 | Point-I Co., Ltd. | Method for transmitting data transmitted incompletely between server and client |
US20100287253A1 (en) * | 2008-01-21 | 2010-11-11 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for data synchronization |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100030846A1 (en) * | 2006-07-28 | 2010-02-04 | Gemalto Sa | Method of synchronization between a mobile equipment unit and a smart card |
US20120278492A1 (en) * | 2008-12-24 | 2012-11-01 | Juniper Networks, Inc. | Using a server's capability profile to establish a connection |
CN102684865A (en) * | 2011-03-07 | 2012-09-19 | 中国移动通信有限公司 | Method, system and device for data synchronization |
Also Published As
Publication number | Publication date |
---|---|
US7570668B2 (en) | 2009-08-04 |
US20030081557A1 (en) | 2003-05-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7570668B2 (en) | Data synchronization | |
KR100716608B1 (en) | Arranging synchronization session | |
EP1628454B1 (en) | A method of and a network for handling wireless session protocol (wsp) sessions | |
JP4829316B2 (en) | Method, apparatus, and system for synchronizing data in response to an interrupted synchronization process | |
US7155521B2 (en) | Starting a session in a synchronization system | |
EP1390874B1 (en) | Synchronization of database data | |
US7571194B2 (en) | Application data synchronization in telecommunications system | |
EP1495610B1 (en) | Method and device for handling synchronization related information | |
RU2390952C2 (en) | Determination of control units in device control system | |
US20060190608A1 (en) | Method for the obtaining of deployment components to electronic devices | |
US20010010685A1 (en) | Method and a device for transferring capability information | |
US7570942B2 (en) | Transactional message-queue communication for wirelessly networked devices system and method | |
WO2010028571A1 (en) | Large data object transmission method, transmission system, transmitting device and receiving device | |
JP2005537579A (en) | Method, apparatus, and system for synchronizing data in response to an interrupted synchronization process | |
US7734728B2 (en) | Addressing a management object | |
KR20030089364A (en) | Method and system of access gateway for integrating wireless internet service on mobile network | |
Alliance | OMA-TS-SyncML_WSPBinding-V1_2-20050509-C |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |