Abstract:
A wireless data delivery platform, on which various content/application developers, and service operators can meet the demands of their wireless subscribers, can not be realized without a unified transport protocol to enable inter-changeability of information delivered between different stand-alone applications. The present invention, a record transport protocol, defines the format of the data sent between various parts of the platform, and between the platform and external clients and servers. Application specific data is extracted and packed into the transport data format and is sent via any transport medium, such as, TCP/IP, HTTP, E-Mail, SMS or through modem.

Description:
FIELD OF THE INVENTION  
         [0001]    This invention relates to a method for data communication in a wireless delivery system, and more specially to a method for converting various data formats into a unified record format to be transported in a wireless data delivery software platform.  
         BACKGROUND OF THE INVENTION  
         [0002]    The wireless Internet is heralded as the next wave of the technology revolution, even though the industry is mostly considered still in its infancy. On the access front, WAP protocol was not designed for rich media and highly interactive contents; while Java falls short on its “Write once, run everywhere” promise. Neither appears to be the right approach in the wireless space. On the other hand, multiple operating systems were proposed for the wireless OS, such as, WinPC, Palm, and many others that are forcing software developers with limited resources to make difficult platform choices. The quest for a software platform that is able to deliver rich, interactive, device integrated wireless information and applications is still in progress.  
           [0003]    Ideally, such a wireless data delivery system should enable carriers, hardware manufacturers, application and content developers to deliver interactive content and applications to customers. Furthermore, it should provide client-server interactivity to major existing and next generation wireless OS platforms, including PocketPC, SmartPhone, Symbian, Java, PalmOS, BREW, and more. In short, a data delivery software platform aims to make it possible for data and application to be delivered on demand across various devices.  
           [0004]    However, as many of the applications available today were initially developed for stand-alone operations, the lack of inter-changeability of information delivered between different applications remains one of the major obstacles to the realization of seamless, integrated software data delivery platform. Among them, the first issue to be addressed, at the core of the aforementioned software platform, is a record transport protocol that defines a unified record format for data delivery.  
         SUMMARY OF THE INVENTION  
         [0005]    The present invention, a record transport protocol, defines a unified record format of the data sent between various parts of the platform, and between the platform and external clients and servers. Application specific data is extracted and packed into the transport data format and is sent via any transport medium, such as, TCP/IP, HTTP, E-Mail, SMS or through modem.  
           [0006]    The present invention provides technology solutions that could be used in a wireless data delivery platform, on which various content/application developers, and service operators can meet the demands of their wireless subscribers. The present invention also aims to leverage effective bandwidth usage of wireless communication standards to deliver an interactive, dynamic, and media-rich user experience.  
           [0007]    The present invention will become more obvious from the following description when taken in connection with the accompanying drawings which show, for purposes of illustration only, a preferred embodiment in accordance with the present invention. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]    [0008]FIG. 1 shows a wireless data delivery platform utilizing the present invention.  
         [0009]    [0009]FIG. 2 shows the unified data format of the present invention.  
         [0010]    [0010]FIG. 3 shows the format of the Application Specific Data Portion in FIG. 2.  
         [0011]    [0011]FIG. 4 shows an embodiment of the present invention used in sending data for adding two phone devices and replacing an old entry to the service. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0012]    [0012]FIG. 1 shows a wireless data delivery software system that the present invention could be used in. The system  101  comprises a platform client  102 , and a platform server  103 . The platform client  102  is responsible for interfacing with various clients, such as a mobile phone  110 , a PDA  111 , a notebook computer  112 , or a desktop PC  113 ; and the platform server  103  provides interface to various application servers  121 . A unified record format, defined by the present invention, must be complied for the data exchanged between any two parts of the system, including all the exchanges between various clients  110 ,  111 ,  112 ,  113 , and the platform client  102 , between platform client  102  and platform server  103 , and between platform server  103  and various application servers  121 .  
         [0013]    When a wireless client  110 ,  111 ,  112 ,  113  requests for a service from an application, a request message is sent from the client to application server  121 . The platform client  102 , upon receiving the request message, converts said request message into a unified record format, shown in FIG. 2, and would be described in further details later. During the conversion, the application specific data is extracted from the request message, and packed into the Application Specific data Portion ( 230  shown in FIG. 2, and further details in FIG. 3). The record, containing the converted request message, is sent to the platform server  103 , then forwarded to targeted application server  121 , where the request is processed, and a result message is sent back to the requesting client  110 ,  111 ,  112 ,  113 . The platform server  103 , upon receiving the result message, converts the said message into the same said unified record format. Similarly, during the conversion, the application specific data is extracted from the result message, and packed into the Application Specific data Portion ( 230  shown in FIG. 2, and further details in FIG. 3). The record, which now contains the converted result message, is forwarded to the platform client  102 , then delivered to said requesting client  110 ,  111 ,  112 ,  113 .  
         [0014]    The unified record format comprises a Format Key  201 , a Transport Header  210 , an Authentication Header  220 , an Application Specific Data Portion  230 , and a Checksum  240 . A Format Key  201 , preceding every message, is to identify the platform on which the message is being delivered. The Transport Header  210 , which starts a message, is further comprising the following fields: a Length field  210   a , a Session ID field  210   b , a Type field  210   c , a Version ID field  210   d , a Flags field  210   e , a Source Application ID field  210   f , a Destination Application ID field  210   g , a Device Address field  210   h , a Packet Count field  210   i , a Packet ID field  210   j.    
         [0015]    The value of the Length field  210   a  indicates the amount of data in bytes that follows the Length field  210   a . The Session ID field  210   b  contains a number that identifies a unique interaction session between a client ( 110 ,  111 ,  112 , or  113 , shown in FIG. 1) and a server ( 121  shown in FIG. 1). The Type field  210   c  provides additional information about the Application Specific Data Portion  230 . The Version ID field  210   d  indicates the version of this format. The Flags field  210   e  contains flags that are used to determine the data type, or indicate the message transmission type, either one-way, which requires no response, or two-way, requiring a response. The Source Application ID field  210   f  contains the ID of the application that originated the message, and the Destination Application ID field  210   g  contains the ID of the application to receive the message, such as stock client, stock server. The Device Address field  210   h  contains the device address, such as its phone number or IP address. The Packet ID field  210   i  contains a number that determines the order of this packet within a group of packets to which this message belongs to make up a complete message, while the Packet Count field  210   j  provides the total number of packets in this session.  
         [0016]    Authentication Header  220  consists of the User Name field  220   a  and the User Key field  220   b . The User Name field  220   a  identifies the account of the owner of the recipient device, such as, a cell-phone, a PDA or a wireless device; and the User Key field  220   b  contains an encrypted string known only to the owner of the account. Both fields are included in all messages except when an external server  121  sends a broadcast type message destined to multiple users, or when the platform server  103  sends a message to an external server  121  that does not use the user account.  
         [0017]    The Application Specific Data Portion  230  contains data that is specific for each application. Its size equals to the value in the Length field  210   a  minus lengths of Transport Header  210 , Authentication Header  220 , and the Checksum  240 . The details of this portion is described in FIG. 3. The Checksum field  240 , provided at the end of each message, contains a CRC-32 checksum of the entire data message, excluding the Checksum field  240  itself. This is to ensure that the entire message was received correctly. If the checksum does not match, or if the message was truncated, the data message would be discarded or an error returned. It a client does not have the processing power to calculate the checksum, the checksum value is set to a fixed value, for example, 0x484D484D (“HMHM”).  
         [0018]    [0018]FIG. 3 shows the data format of the Application Specific Data Portion  230  in FIG. 2. Its format must be understood by the platform so that certain filtering or transforming processes performed within the platform could take place. It comprises the following fields: an Action Count field  301 , indicating the number of actions described in this message; an Action ID field  302 , determined by the source and destination application, whose value is not universally unique between applications, but only unique within the scope of the application server and the application clients; a Field Count field  310 , which gives the total number of fields sent in each record, followed by a list of Field ID  310   a ,  310   b , and so on; a Record Count field  319  indicating the number of records in this message, followed by a list of records  320 ,  330 . Each record  320 ,  330  is further comprising a number of Length-Data field pairs. As shown in FIG. 3, a record  320  contains a Length field  321   a  and a Data field  321   b  pair, and a Length field  322   a  and a Data field  322   b  pair, and so on. The Length field indicates the amount of data in the following Data field; while the Data field contains the actual data.  
         [0019]    [0019]FIG. 4 shows an embodiment of the present invention when a client sends a data message to the server to add two phone book entries, and to replace one phone book entry in a phone book synchronization application. The fields sent are the display name and the cell phone number. In this example, the value contained in the User Key field is not an actual generated key.  
         [0020]    While we have shown and described the embodiment in accordance with the present invention, it should be clear to those skilled in the art that further embodiments may be made without departing from the scope of the present invention.