HK1070152A - Data synchronization interface - Google Patents

Description

Data synchronization interface

Reference to related applications

This application claims the right to copending provisional application serial No. 60/312,737 filed on 8/15/2001, which is hereby incorporated by reference in its entirety.

Background

I. Field of the invention

The present invention relates generally to communication between systems, and more particularly to a communication interface for facilitating data and information transfer between systems and/or databases.

Related Art

Wireless devices, such as cellular telephones, personal digital assistants ("PDAs"), pagers, laptop computers with wireless connectivity, and the like, communicate packets containing voice and data over a wireless network. These wireless devices have application programming interfaces ("APIs") installed on their local computer platform that allow software developers to create software applications that run on the wireless devices. The API interfaces the system software and software applications of the wireless device so that the applications can use the functionality of the wireless device without the software developer having to own the specific wireless device system source code.

These wireless devices typically need to communicate with other systems and databases in other systems. Unfortunately, wireless devices may lose signals during communication or may be unavailable for use in transmitting information to other systems. When the signal is lost, an error will result if an attempt is made to access the database. When the signal is reacquired, the wireless device needs to restart the database access and resubmit the database request.

To extend the range away from wireless devices, wired systems often need to communicate with each other, but do not share a similar communication "language". For example, as with a wireless device, one system may need to communicate with a database in another system to receive or insert data. To communicate with a database, the system must be able to identify the database language, the structure and format of records and domains in order to access the database and store information. While current technology provides the capability for an interface between a system and a database to include the language, structure and format of the database, it becomes more complex when access is required to multiple databases, such as may require multiple unique database languages.

In addition, when data is sent to or received from multiple systems, a shared interface is absent to integrate the multiple systems, thereby simplifying data transmission. This is a problem for systems that communicate with multiple other systems.

What is needed in the art, therefore, is an interface that facilitates communication between one or more databases and provides reliable and secure information transfer between multiple systems.

The prior art methods do not address this need. If multiple databases need to be accessed, the database replication service and custom building of the database interface becomes very complex and difficult to manipulate. In addition, all systems that require access to custom databases must be provided with this interface. At the same time, the custom built database must remain online in preparation for the transaction to occur.

Electronic data interchange ("EDI") focuses only on the requirements of predefined information types and content for a particular electronic business. The EDI information format does not address the data exchange requirement as it relates to wireless services, system integration considerations, and billing features.

Summary of The Invention

The system and method in accordance with the present invention overcomes the disadvantages of existing systems by allowing an application to access resources of a device based on a set of permissions associated with the application.

In one embodiment, the present invention provides a method of processing information in an interface, including receiving information in a first format from a source system, storing data in a persistent intermediate storage, initiating transfer of the information to a target system while retaining the information, receiving an indication that the transfer of the information to the target system was unsuccessful, and restarting the transfer of the information to the target system. The method also includes storing information received from a plurality of source systems associated with the plurality of target systems and initiating a data transfer from the plurality of source systems to the associated plurality of target systems. The method may also include receiving an acknowledgement from the source system indicating that an acknowledgement has been received from the target system, and deleting the data from the persistent intermediate storage.

Other objects, advantages and features of the present invention will become apparent from the following brief description of the drawings, detailed description of the invention and the claims.

Brief description of the drawings

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate presently preferred embodiments of the invention and, together with the general description given above and the detailed description of the preferred embodiments given below, serve to explain the principles of the invention. In the drawings:

FIG. 1 is a schematic diagram of a wireless network and computer hardware and wireless devices that can be used in exemplary embodiments of the present invention;

FIG. 2 is a block diagram of the hardware components of a wireless network that provides communication between different wireless devices, application download servers, and databases in an example embodiment of the invention;

FIG. 3 is a block diagram depicting the structure of a detect synchronizer tool interface in an exemplary embodiment of the invention; and

fig. 4 is a flow chart depicting the operation of the synchronizer tool interface in an exemplary embodiment of the present invention.

Detailed description of the invention

Reference will now be made in detail to the present exemplary preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to the like or corresponding parts throughout. The features, objects, and advantages of the present invention will become more apparent to those skilled in the art from the following detailed description when read in conjunction with the accompanying drawings.

Fig. 1 depicts an architecture in which an embodiment of the present invention may be implemented using one or more wireless devices, such as a cellular telephone 12. The wireless device communicates with at least one network server, such as an application download server 16, across the wireless network 14, and the server 16 selectively downloads or provides access to software applications and other data to the wireless device through a wireless communication portal or other data access to the wireless network 14. As shown, the wireless device may be a cellular telephone 12 having a graphics display 13, a personal digital assistant 18 having a PDA screen 19, a pager 20 having a graphics display 21, which is shown here as a two-way text pager, or even a separate computer platform 22 that has a wireless communication portal and a display 23 and that may have a wired connection 24 to a network or the Internet. The system 10 may include any form of remote computer module having a wireless communication portal, including but not limited to: a wireless modem, a PCMCIA card, an access terminal, a personal computer, an access terminal, a telephone without a display or keypad, or any combination or sub-combination thereof.

The application download server 16 is shown on a local server-side network 26 in communication with the wireless network 14 along with other computer components, such as a database 28 containing applications, data containing software applications, and data accessible and downloadable by the wireless devices 12, 18, 20, 22.

Fig. 2 is a block diagram of wireless network hardware components that provide communication between different wireless devices, an application download server, and a database in an example embodiment of the invention. The wireless network 14 is merely an example and can comprise any system whereby remote modules, such as wireless devices 12, 18, 20, 22, communicate over-the-air between and among each other and/or between and among components of a wireless network 14, including, without limitation, wireless network carriers and/or servers. The application download server ("ADS") 16 and the stored application database 28 will be set up on the cellular digital network, along with any other components needed to provide cellular telecommunication services. The server 32 also provides other functions used by one or other components, such as application management functions of an application download server. The server 32 and ADS use a synchronizer interface tool (not shown) to pass data between the systems. A server or other component of the system may interface with other systems not shown here to send or receive data. Synchronizer tools may also be used to support communication with these other systems.

The application download server 16 and/or other servers communicate with the carrier network 40 via a data link, such as the internet, a secure local area network, a wide area network, or other network. The carrier network 40 controls information (typically data packets) that is sent to an information service controller ("MSC") 42. The carrier network 40 communicates with the MSC 42 by a network, i.e., the internet and/or POTS ("plain ordinary telephone system"). Typically, the network or Internet connection between the carrier network 40 and the MSC 42 is used to transmit data, and POTS is used to transmit voice information. The MSC 42 is coupled to a plurality of base stations ("BTSs") 44. Like the carrier network, the MSC 42 is typically coupled to the BTS 44 by both the network and/or Internet for transmitting data and POTS transmission for voice information. The BTS 44 ultimately broadcasts messages wirelessly to wireless devices, such as cellular telephones 12, via short message service ("SMS"), or other over-the-air means known in the art.

The wireless device, such as cellular telephone 12, has a computer communications platform 50 that is capable of receiving and executing software applications and displaying data transmitted from the application download server 16. The computer platform 50 also enables the wireless device to interact with data and applications resident on the network server. The computer platform 50 includes a display driver 52 for driving the graphics display 13 and rendering images on the graphics display 13 based on graphics data received at the computer platform 50. The computer platform 50 also includes an application specific integrated circuit ("ASIC") 54 or other processor, microprocessor, logic circuit, or other data processing device. The ASIC 54 is installed at the time of wireless device production and is not normally upgradeable. The ASIC 54 or other processor executes an application programming interface ("API") layer 56 that interfaces with any resident programs in the wireless device memory 58. Memory may include read-only or random-access memory (RAM and ROM), EPROM, EEPROM, flash cards, or any memory common to computer platforms. The computer platform 50 also includes a local database 60 that stores software applications not actively used in the memory 58, such as software applications downloaded from the application download server 16. Local database 60 is typically comprised of one or more flash memory cells, but may be any secondary or tertiary storage device as known in the art, such as magnetic media, EPROM, EEPROM, optical media, tape, or soft/hard disk.

Wireless devices, such as cellular telephone 12, are capable of accessing and downloading many types of applications, such as games and stock monitoring, or simply data such as news and sports related data. The downloaded data may be displayed immediately on the display or stored in the local database 60 when not in use. The software applications may be considered conventional software applications resident on the wireless device 12, 18, 20, 22, and a user of the wireless device may selectively upload stored resident applications from the local database 60 to the memory 58 for execution on the API 56. The end-user of the wireless device 12, 18, 20, 22 may also selectively delete the software application from the local database 60.

FIG. 3 is a block diagram depicting the structure of a synchronizer tool interface in an example embodiment of the invention. In one embodiment, synchronizer tool 305 enables tables in an RDBMS system to be synchronized with the target system through a standard XML interface. Those skilled in the art recognize that the XML language is one implementation choice, and that other languages may be used. Further, it is recognized that synchronizer tools may be used to synchronize or pass other information between computer systems or subsystems, and are not limited to information from RDBMS tables. In addition, the connection between the interface and the target and source systems may be via any communication medium, such as wireless, including RF, satellite, and infrared communications, as well as wired communication methods. In one embodiment, the communication medium is an IP-based medium.

Data received from RDBMS 320 in source system 310 is stored in queue 325 of synchronizer tool 305. The data is converted to a common file format, such as XML. Through a storage mechanism like a queue, the synchronizer tool can retain the data of RDBMS315 even if source system 310 is offline. The synchronizer tool 305 may also be implemented to provide an acknowledgement to the source system 310 when data sent to the target system 315 is repeated in the RDBMS315 (the target system may provide an acknowledgement to the synchronizer tool 305 indicating that a repeat occurred, acknowledging receipt of the data, or performing other processing).

Source system 310 is connected to synchronization tool 305. The connection may be through any communication mechanism, including wireless and/or wired connections (or a combination of both). Synchronizer tool 305 may be local to the source system or remote. The source system sends information to the synchronizer tool through this connection. The information may be data for copying to a remote database, or may be any type of information directed to another system, such as a message request, data request, or other data transmission. In one embodiment, source system 310 sends this information to synchronizer tool 305 in XML format.

The target system receives information from synchronizer tool 305 and may respond with an acknowledgement to synchronizer tool 305. Alternatively, the synchronizer tool may interact directly with a subsystem (e.g., RDBMS315) in the target system 300 to perform tasks such as data replication.

It must be noted that the definition of target system 300 and source system 310 is somewhat arbitrary. In one event one system may be a source system for transmitting data to a target system, but in another event the system may be a target system for receiving data transmitted from another system.

FIG. 4 is a flow chart depicting the operation of the synchronizer tool interface in an exemplary embodiment of the present invention. In this method, the source system is first caused to convert the data into XML format (step 400) or other common format. The data may be in the form of scalar data for the target system, a request for information for the target system, or other information that is communicated for processing by the target system. The data is then sent to and received by the synchronizer tool (step 405).

The data is stored in persistent intermediate memory (step 405), such as a queue within a synchronizer tool. This allows some degree of independence between the source system and the target system. The source system may generate requests, store them in a queue, and may be offline as the requests are transmitted to and processed by the target system. Alternatively, the synchronizer tool may send a positive acknowledgement to the source system confirming receipt of the data.

The data is then sent from the synchronization tool to the target system in XML format (step 415). It must be noted that "data" may be any information that needs to be sent to the target system. It may be data that is used to copy to the target system RDBMS. Or any type of command or information sent to the target system so that it can be processed by the target system. In addition, there may be multiple target systems receiving the data. The synchronizer tool can queue a plurality of data transfer requests for a plurality of destinations, the requests including multi-destination system destination requests.

The method then continues to initiate the translated command on the RDBMS (step 415). When a command is translated into a language suitable for the target system RDBMS, it may initiate the command by direct access to the target system RDBMS or by sending the command to a processor, such as a processor in the target system.

If the target system receives the data (step 420), the yes branch is taken and an acknowledgement is sent to the source system (step 425). The source system formats the acknowledgement into a format readable by the source system, such as XML. If the source system is not online, the acknowledgement is queued and further attempts are made to the source system to notify it that data has been sent to the target system. The synchronizer tool can determine whether the target system has received the data by receiving an acknowledgement from the target system.

If data is received at the target system, as determined in step 420, such as would occur if the target system or RDBMS were offline, the no branch is taken and the data is held in a queue and retried (step 430) to initiate the transfer of the data to the target system as described in step 415. There are many queuing algorithms and time parameters that can be used to determine when to initiate another transmission to the target system. The preferred algorithm and time are determined by the processing capacity, efficiency, available resources (e.g., available queuing memory), and other implementation factors of the present system.

The foregoing description of one implementation of the invention is illustrative and explanatory thereof. It is not intended to be exhaustive or to limit the invention to the precise form described. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, the above-described embodiment is implemented by software, but an embodiment of the present invention may be implemented in a combination of hardware and software or in hardware alone. The present invention may be implemented in both object-oriented and non-object-oriented programming systems. In addition, although aspects of the present invention are stored in memory, it will be apparent to those skilled in the art that these aspects may also be stored on other types of computer-readable media, such as secondary storage devices, e.g., hard disks, floppy disks, or CD-ROMs; a carrier or other propagation medium from the internet; or other forms of RAM or ROM.

Further, it is to be noted that various changes and modifications may be made herein without departing from the scope of the invention as defined by the appended claims and their equivalents. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.

Claims (11)

1. A method for processing information, comprising:

receiving information in a common format from a source system;

storing the information;

starting the transmission of information to the target system, and simultaneously retaining the information;

receiving a target system acknowledgement indicating that the target system has received the information; and

and sending the positive response to the source system after receiving the positive response of the target system.

2. The method of claim 1, wherein the common format is an XML format.

3. The method of claim 1, wherein the target system is a database, and the information comprises data for replication in the database.

4. The method of claim 1, wherein the information is a command directed to a target system, and wherein sending the target system acknowledgement indicates that the command has been processed.

5. A method for processing information in an interface, comprising:

receiving data in a first format from a source system;

storing the data in a persistent intermediate memory;

starting the transmission of information to the target system, and simultaneously retaining the information;

receiving an indication that the transmission of the information to the target system was unsuccessful; and

transmission of the information to the target system is restarted.

6. The method of claim 5, further comprising:

storing data received from a plurality of source systems associated with a plurality of target systems;

initiating transfer of data from a plurality of source systems to an associated plurality of target systems;

7. the method of claim 5, further comprising:

receiving a source system acknowledgement indicating that an acknowledgement has been received; and

the data is deleted from the persistent intermediate storage.

8. An interface, characterized in that it comprises:

a connection to a source system and a target system;

a memory for storing data from the source system;

a processor configured to receive data from the source system, store the data in the memory, initiate a transfer of the data to the target system, receive a target system acknowledgement from the target system, and send the acknowledgement to the source system.

9. The interface of claim 8, wherein the processor is further configured to restart transmission of data to a target system.

10. A system for processing information in an interface, comprising:

means for receiving information in a common format from a source system;

means for storing said information;

means for initiating transmission of information to the target system while retaining the information;

means for receiving a target system acknowledgement indicating that the target system has received the information; and

and means for sending an acknowledgement to the source system when the target system acknowledgement is received.

11. A computer-readable medium containing computer-executable instructions for allowing access to a device resource, the instructions when executed performing a method comprising:

receiving information in a common format from a source system;

storing the information;

initiating transmission of the information to the target system while retaining the information;

receiving a target system acknowledgement indicating that the target system has received the information; and

and when the acknowledgement of the target system is received, the acknowledgement is sent to the source system.