Patent Publication Number: US-7899474-B2

Title: Associating a label with a queued message at a mobile device

Description:
COPYRIGHT NOTICE 
     A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
     FIELD OF TECHNOLOGY 
     The present disclosure relates to storage of a message in a queue at a mobile communication device before transmission of the message and, more particularly, to the association of a label with the stored message. 
     BACKGROUND 
     A mobile communication device typically maintains a queue of outbound data to be sent to a destination. The data stored in the queue may, for instance, be messages destined for a server. Such messages may include messages that are formed as requests for information from the server and messages that are formed as updates to information previously stored on the server. Broadly, the messages may be considered elements of a data transaction between the server and the mobile device. Typically, the queue is used only in a transient manner while the mobile device is in coverage range. The queue is of particular use when the mobile device is not in communication with the server. That is, when the mobile device is not within a coverage range of any suitable wireless communications base stations. Typically, after being out of coverage range, when the mobile device enters a coverage range, the mobile device automatically sends the queued messages to the server. 
     Unfortunately, queuing may be required for extended periods. For instance, the mobile device may be out of coverage for the extent of a long journey aboard an airplane. By the time a given queued message is sent, the given queued message may be out of date. 
     A user of the mobile device may elect to inspect the queue and, thereby, determine, for example, that there are five outgoing messages in the queue. It is common that the outgoing messages are formatted in the known Extensible Markup Language (XML) or a variant thereof. As such, when the queue is inspected by the mobile device user, each outgoing message may be displayed in raw XML. This format may be difficult for an average mobile device user to comprehend. The situation may be compared to a network print queue in which items representing print jobs are undecipherable by a typical network user. As a result, the user may not understand the nature of the messages that are queued and may be ill-informed to re-attempt transmission or take other courses of action for urgent messages. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the figures which illustrate example embodiments of this application: 
         FIG. 1  illustrates elements of an exemplary network environment for a wireless mobile communication device; 
         FIG. 2  illustrates, in greater detail, the wireless mobile communication device of  FIG. 1  according to an embodiment of the present disclosure; 
         FIG. 3  illustrates elements of a virtual machine according to an embodiment of the present disclosure; 
         FIG. 4  illustrates steps of an exemplary method of generating a message associated with a label according to an embodiment of the present disclosure; and 
         FIG. 5  illustrates steps of an exemplary method of presenting a display of contents of a queue according to an embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Each type of message to be transmitted from a mobile device may be defined to be associated with a label, where the label may provide a generic description (e.g., “New mail message”, “Status update”, etc.), to display when a message of that type is present in a queue of outbound messages. Responsive to the sensing of an occurrence of an event, a message is generated. The message may be generated with a format that is based on an application definition document. According to the application definition document, a label may be generated for associating with the message. The message and label may then be stored in a queue in a manner that allows the label to be associated with the message. Subsequent to the message having been stored, a representation of the queue may be displayed for review by a user interested in the status of the message, or the queue in general. The label associated with the message is displayed in the representation rather than the actual code of the message, thereby allowing the viewer of the display to make an informed decision regarding further activity to carried out on the message. 
     In accordance with an aspect of the present disclosure there is provided a method of handling outgoing messages. The method includes receiving a document that defines an explicit format for outgoing messages, said format including delimiters for defining the beginning and end of a message generated according to said format, and generating, according to the format, a message. The method further includes generating a label for the message based on information provided in the document, storing the message in a queue and storing the label in the queue associated with the message. In other aspects of the application, a mobile communication apparatus is provided to carry out the method and a computer readable medium is provided to allow a processor in a mobile communication device to carry out the method. 
     Other aspects and features of the present disclosure will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the application in conjunction with the accompanying figures. 
       FIG. 1  illustrates elements of an exemplary network environment  100  for a wireless mobile communication device  101 . The elements of the exemplary network environment  100  include a wireless carrier core network subsystem  106  and a data communication network  108 , which may be considered to represent at least one wide area network, such as the present day Internet and successors, as well as, potentially, multiple local area networks. A base station antenna  102 , with which the mobile device  101  may communicate wirelessly, is provided as part of a base station subsystem  104 . 
     The base station subsystem  104  communicates with the wireless core network subsystem  106 . In an exemplary Global System for Mobile communications (GSM) implementation, the wireless core network subsystem  106  includes, among other components, a mobile services switching center, a home location register, a visitor location register and a Short Messaging Service Center. As illustrated in  FIG. 1 , the wireless core network subsystem  106  may be connected to the data communication network  108  and to a Public Switched Telephone Network (PSTN)  122 . 
     The mobile device  101  may be associated with an enterprise  110  that is in communication with the data communication network  108 . The enterprise  110  may, for instance, include a firewall or proxy server  11   2  connecting to the data communication network  108  and to a local area network (LAN)  114 . The LAN  114  may allow communication between a mobile device server  116 , an enterprise server  118  and a transaction server  120  within the enterprise. 
     Also connected to the data communication network  108  may be a relay  130  and a backend application server  132 . 
       FIG. 2  illustrates the wireless mobile device  101  including a housing, an input device (a keyboard  210 ), and an output device (a display  226 ), which is preferably a full graphic or full color Liquid Crystal Display (LCD). Other types of output devices may alternatively be utilized. A processing device (a microprocessor  228 ) is shown schematically in  FIG. 2  as coupled between the keyboard  210  and the display  226 . The microprocessor  228  controls the operation of the display  226 , as well as the overall operation of the mobile device  101 , in response to actuation of keys on the keyboard  210  by a user. 
     The housing may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keyboard  21   0  may include a mode selection key, or other hardware or software, for switching between text entry and telephony entry. 
     In addition to the microprocessor  228 , other parts of the mobile device  101  are shown schematically in  FIG. 2 . These include: a communications subsystem  240 ; a short-range communications subsystem  202 ; the keyboard  210  and the display  226 , along with other input/output devices including a set of auxiliary I/O devices  206 , a serial port  208 , a speaker  211  and a microphone  212 ; as well as memory devices including a persistent flash memory  216  and a Random Access Memory (RAM)  218 ; and various other device subsystems  220 . The mobile device  101  is preferably a two-way radio frequency (RF) communication device having voice and data communication capabilities. In addition, the mobile device  101  preferably has the capability to communicate with other computer systems via the Internet. 
     Operating system software executed by the microprocessor  228  is preferably stored in a computer readable medium, such as the flash memory  216 , but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the RAM  218 . Communication signals received by the mobile device  101  may also be stored to the RAM  218 . 
     The microprocessor  228 , in addition to its operating system functions, enables execution of software applications on the mobile device  101 . A predetermined set of software applications that control basic device operations, such as a voice communications module  230 A and a data communications module  230 B, may be installed on the mobile device  101  during manufacture. An application client subsystem module  230 C may also be installed on the mobile device  101  during manufacture, to implement aspects of the application. In particular, the application client subsystem module  230 C may include virtual machine software. 
     Additional software modules, illustrated as an other software module  230 N, which may be, for instance, a personal information manager (PIM) application, may be installed during manufacture. The PIM application is preferably capable of organizing and managing data items, such as e-mail messages, calendar events, voice mail messages, appointments, and task items. The PIM application is also preferably capable of sending and receiving data items via a wireless carrier network represented in  FIG. 2  by the base station antenna  102 . Preferably, the data items managed by the PIM application are seamlessly integrated, synchronized and updated via the wireless carrier network with the mobile device  101  user&#39;s corresponding data items stored at, or associated with, the enterprise server  118 . 
     Communication functions, including data and voice communications, may be performed through the communication subsystem  240  and, possibly, through the short-range communications subsystem  202 . The communication subsystem  240  includes a receiver  250 , a transmitter  252  and one or more antennas, illustrated as a receive antenna  254  and a transmit antenna  256 . In addition, the communication subsystem  240  also includes a processing module, such as a digital signal processor (DSP)  258 , and local oscillators (LOs)  260 . The specific design and implementation of the communication subsystem  240  is dependent upon the communication network in which the mobile device  101  is intended to operate. For example, the communication subsystem  240  of the mobile device  101  may be designed to operate with the Mobitex™, DataTAC™ or General Packet Radio Service (GPRS) mobile data communication networks and may also be designed to operate with any of a variety of voice communication networks, such as Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Personal Communications Service (PCS), GSM, etc. Other types of data and voice networks, both separate and integrated, may also be utilized with the mobile device  101 . 
     When the required network registration or activation procedures have been completed, the mobile device  101  may send and receive communication signals over the wireless carrier network. Signals received from the base station antenna  102  by the receive antenna  254  are routed to the receiver  250 , which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP  258  to perform more complex communication functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the base station antenna  102  are processed (e.g., modulated and encoded) by the DSP  258  and are then provided to the transmitter  252  for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the base station antenna  102  via the transmit antenna  256 . 
     In addition to processing communication signals, the DSP  258  provides for control of the receiver  250  and the transmitter  252 . For example, gains applied to communication signals in the receiver  250  and the transmitter  252  may be adaptively controlled through automatic gain control algorithms implemented in the DSP  258 . 
     In a data communication mode, a received signal, such as an SMS message or web page download, is processed by the communication subsystem  240  and is input to the microprocessor  228 . The received signal is then further processed by the microprocessor  228  in preparation for output to the display  226  or, alternatively, to some of the auxiliary I/O devices  206 . A device user may also compose data items, such as e-mail messages or SMS messages, using the keyboard  210  and/or some other auxiliary I/O device  206 , such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device. The composed data items may then be transmitted to the base station antenna  102  via the communication subsystem  240 . 
     In a voice communication mode, overall operation of the mobile device  101  is substantially similar to the data communication mode, except that received signals may be output to the speaker  211 , and signals for transmission may be generated by the microphone  212 . Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the mobile device  101 . In addition, the display  226  may also be utilized in voice communication mode, for example, to display the identity of a calling party, the duration of a voice call, or other voice call related information. 
     The short-range communications subsystem  202  enables communication between the mobile device  101  and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem  202  may include an infrared device and associated circuits and components, or a Bluetooth™ communication module, to provide for communication with similarly-enabled systems and devices. 
     The virtual machine software of the application client subsystem module  230 C may include: conventional XML parser software; event handler software; screen generation engine software; and object classes. The software, when executed, leads to a virtual machine  300 , which, as illustrated in  FIG. 3 , includes: an XML parser  302 ; an event handler  304 ; a screen generation engine  306 ; and instances  308  of the object classes. The instances  308  correspond to XML elements supported by the virtual machine software and possibly other XML elements contained within an application definition document. Supported XML elements are detailed in Appendix A hereto attached. A person of ordinary skill will readily appreciate that those XML elements identified in Appendix A are exemplary only and may be extended or shortened as desired. An XML element is a form of markup language element. 
     From the perspective of the mobile device  101 , the transaction server  120  is positioned behind the firewall  112 . In operation, the transaction server  120  may exchange data traffic with the enterprise server  118 . Additionally, the transaction server  120  may exchange data traffic with the backend application server  132 . In an exemplary case, the virtual machine  300 , executing on the microprocessor  228  of the mobile device  101 , generates a request message and stores the request message in a queue of outbound messages. A message transmission object then transmits the request message to the transaction server  120 , via the base station subsystem  104 , the wireless network subsystem  106 , the data communication network  108 , the firewall  112  and the local area network  114 . Responsive to receiving the request message, the transaction server  120  may execute a database query on a database. The response to the database query may, for instance, be an indication of server-side applications that are available to the mobile device  101 . Data representative of the indication may then be transmitted, by the transaction server  120  in a response message, to the mobile device  101 . 
     Upon receipt of the response message at the mobile device  101 , the screen generation engine  306  of the virtual machine  300  may present a list of available server-side applications in a user interface on the display  226  of the mobile device  101 . In response to being presented with the list of available server-side applications, a user at the mobile device  101  may select a given server-side application for which to register. Responsive to the user selecting the given server-side application, the virtual machine  300  generates a registration request message containing a registration request for the given server-side application and stores the registration request message in the outbound message queue. The message transmission object then transmits the registration request message to the transaction server  120 . The transaction server  120 , in response to receiving the registration request message, queries the server database for a user interface definition associated with the given server-side application and the mobile device  101 . Thereafter, the transaction server  120  creates an application definition document, which includes the user interface definition, and transmits a message that includes the application definition document to the mobile device  101 . 
     At the mobile device  101 , the application definition document carrying message is received (step  402 ,  FIG. 4 ). After receiving the application definition document carrying message, the XML parser  302  of the virtual machine  300  may parse the text of the application definition document and the screen generation engine  306  may generate, according to the user interface definition, a user interface for presentation on the display  226  of the mobile device  101 . Some time after receipt of the application definition document and using the user interface, a user could trigger the transmission, by the mobile device  101 , of a login request to transaction server  120 . The login request is received by the transaction server  120  and subsequently transmitted to the server hosting the given server-side application (e.g., the enterprise server  118  or the backend application server  132 ). The server hosting the given server-side application, according to the logic embedded within the given server-side application, returns a login response to the transaction server  120 , which login response the transaction server  120  transmits to the mobile device  101 . Subsequent traffic related to the given server-side application, for instance, messages to be transmitted from the mobile device  101  to the server hosting the given server-side application, also flows through the transaction server  120 . 
     As may be understood from the preceding, the transaction server  120  may be considered to manage the flow of data between an application executed at a server and an interface to that application presented at the mobile device  101 . Among other operating systems, the transaction server  120  may be implemented on Microsoft™ Windows 2000 or Windows 2003 server. The collection of functions executed at the transaction server  120  may be considered to include application management, access control, event monitoring, session control, transaction queuing, data routing, user management and network connectivity monitoring. 
     In overview, the application client subsystem module  230 C may provide instructions to allow the microprocessor  228  to generate a message of a given type for transmission to the transaction server  120  ( FIG. 1 ). In conjunction with storing the generated message in the outbound message queue, the microprocessor  228  may also store a label such that the label is associated with the stored message. The microprocessor  228  may use a label specified, in the application definition document, for messages of the given type. 
     As is known in the art, the outbound message queue may be implemented as a “queue table” in a relational database, say, in the persistent flash memory  216 . Relational databases may be structured to include tables, which contain records. As such, an outbound message may be stored in a Message field of a message record in the queue table. Advantageously, a new field, a “Label” field, may be defined for the message record, where the Label field is arranged for storage of a label associated with the message stored in the Message field of the message record. 
     When the mobile device user elects to review the contents of the queue table, a user interface executed on the mobile device may display the label representative of the message. The mobile device user may then take further action. For instance, the mobile device user may interact with the user interface to delete, from the queue table, a message deemed to be out of date. Alternatively, the mobile device user may interact with the user interface to request that transmission of the messages in the queue table be re-attempted. Ideally, the label is sufficient to allow the user to understand the nature of the queued message so that the user may make a subsequent, informed decision. 
     As discussed above, an application definition document provides a user interface definition. Overall, the application definition document may define for a particular server-side application: a user interface for controlling application functionality and display format (including display flow); the format of data to be exchanged over the data communications network  108 ; and the format of data to be stored locally at the mobile device  101 . The virtual machine may use the operating system software, also executed by the microprocessor  228 , and associated application programming interfaces (APIs) to interact with elements of the mobile device  101  in accordance with the received application definition document. In this way, the mobile device  101  may present interfaces for a variety of applications executed at a variety of remote application servers. 
     While creating an application definition document, a developer may have an opportunity to define a number of types of messages to be sent by the mobile device  101  to the transaction server  120  (some of which may be destined for the backend application server  132  or the enterprise server  118 ). To implement aspects of the present disclosure at design time, a developer may specify, for a specific type of message, a label to be associated with a queued message. 
     As presented in the previously cited US patent application Publication 2003/0060896, an exemplary application definition document may be formed using a markup language, such as the known XML or a variant thereof. In accordance with an embodiment of the present disclosure, defined XML elements are interpreted by the virtual machine  300  and may be used as building blocks to present, at the mobile device  101 , an interface to server-side applications. 
     Instances  308  of virtual machine object classes allow the mobile device  101  to process each XML element of a set of supported XML elements. Each of the object classes may be defined to include, for each supported XML element: attributes, which may be used to store parameters defined by the application definition document; and functions, which allow the XML element to be processed at the mobile device  101 . As such, the developer may specify a label as an attribute of a XML element in an application definition document. 
     Appendix B provides an exemplary application definition document whose format should be familiar to those skilled in the art of developing markup language documents. The text &lt;SCREENS STSCRN=“GETQUOTE”&gt; begins a definition of a screen named “GETQUOTE”. As part of the screen definition and, further, as part of a definition of a MENU element for a menu with a NAME attribute of “mnuMainMenu”, a MENUITEM element with NAME attribute “GetQuote” is defined. The MENUITEM element with NAME attribute “GetQuote” includes an EVENT element with a TYPE attribute “MENUITEMSELECTED”. The EVENT element with a TYPE attribute “MENUITEMSELECTED” is associated with three ACTION elements, having TYPE attributes of: “OPEN”; “SAVE”; and “ARML”. 
     The following is a portion of a further exemplary application definition document. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;BTN NAME=“btnSend” INDEX=“5” CAPTION=“Send” X=“80” 
               
               
                   
                 Y=“248” HT=“21” WT=“76” &gt; 
               
               
                   
                  &lt;EVENTS&gt; 
               
               
                   
                   &lt;EVENT TYPE=“BUTTONCLICK”&gt; 
               
               
                   
                    &lt;ACTION TYPE=“ARML” MSG=“Message To 
               
               
                   
                    [SP.MAIL.TO]”&gt; 
               
               
                   
                     &lt;ARMLTEXT&gt; 
               
               
                   
                      &lt;PKG TYPE=“NEWMSG”&gt; 
               
               
                   
                       &lt;MSG ID=“[SP.*.ID]” 
               
               
                   
                       SUBJECT=“[SP.MAIL.SUBJECT]” 
               
               
                   
                       BODY=“[SP.MAIL.BODY]” 
               
               
                   
                       TO=“[SP.MAIL.TO]”/&gt; 
               
               
                   
                      &lt;/PKG&gt; 
               
               
                   
                     &lt;/ARMLTEXT&gt; 
               
               
                   
                    &lt;/ACTION&gt; 
               
               
                   
                   &lt;/EVENT&gt; 
               
               
                   
                  &lt;/EVENTS&gt; 
               
               
                   
                 &lt;/BTN&gt; 
               
               
                   
                   
               
            
           
         
       
     
     According to the above application definition document portion, the XML element that defines an ACTION element with TYPE attribute “ARML” includes an attribute “MSG” whose value field is provided as “Message To [SP.MAIL.TO]”. The value field of the MSG attribute may contain a label representative of the nature of the message. 
     Notably, the value field of the MSG attribute is arranged to be completed dynamically from data provided by the user, for instance, into edit boxes presented on the display of the mobile device. The value field of the MSG attribute includes a placeholder delimited by square brackets, i.e., “[” and “]”. The placeholder reference a data source from which data for filling the corresponding section of the value field should be obtained. A suitable data source might be a user interface field on a current screen, a user interface field on a previous screen or a table in a device-based logical database. The virtual machine  300 , after reading the data source name, searches for the field corresponding to the referenced data source and replaces the placeholder with data contained within the named field. In this example, the value field of the MSG attribute references [SP.MAIL.TO]. As such, content for the value field of the MSG attribute may be read from a field named “TO” on a screen named “SP.MAIL”. 
     Additionally, the PKG element to be generated responsive to an event of type “BUTTONCLICK” is also arranged to be completed dynamically based on data provided by the user. 
     In operation, the virtual machine  300  executed on the microprocessor  228  may control the presentation, on the display  226  of the mobile device  101 , of a button displaying a caption “Send” according to the above exemplary application definition document portion. The user of the mobile device  101  may select the button such that an event of the type “BUTTONCLICK” is detected by the operating system of the mobile device  101 . The operating system may indicate the detected event to the event handler  304  of the virtual machine  300 . The event handler  304  may, based on the definition of the BTN element in the application definition document portion, arrange for the performance of an action, defined by an ACTION element, by the virtual machine  300 . 
     According to the ACTION element of type ARML defined in the application definition document portion above, the event handler  304  instantiates an instance of an object class corresponding to the ACTION element of type ARML. The instance then calls a message generation method to generate a message (step  404 ,  FIG. 4 ) for transmission to the transaction server  120 . 
     The above application definition document portion provides a format, according to which the message generation method may generate the message. According to the format, the message is a PKG element delimited by &lt;PKG&gt;&lt;/PKG&gt; tags. The PKG element has a TYPE attribute. Within the PKG element, the message payload is a MSG element. The MSG element has attributes named “ID”, “SUBJECT”, “BODY” and “TO”. Each of the attributes references a placeholder. 
     The message generation method may, based on the format, add text to a string variable. As mentioned above, elements of the application definition document, including elements of the action, have been parsed by the XML parser  302 . The message generation method adds successive portions of the message to the string variable, such as “&lt;PKG TYPE=”NEWMSG“&gt;”, then “&lt;MSG”, then “ID=””, etc. Before adding the next portion, the message generation method resolves the placeholder “[SP.*.ID]” and adds the text to which the placeholder resolves. In an exemplary resolution of a placeholder, the user has inserted the text “Hello World” in the SUBJECT edit box on the SP.MAIL screen, the message generation method may read the contents of the edit box and add the text “Hello World” to the string variable. 
     An exemplary message generated according to message format provided in the above exemplary application definition document portion may appear as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;PKG TYPE=“NEWMSG”&gt; 
               
               
                  &lt;MSG ID=“98378734” SUBJECT=“Hello World” BODY=“Sample 
               
               
                  Message” TO=“John Doe”/&gt; 
               
               
                 &lt;/PKG&gt; 
               
               
                   
               
            
           
         
       
     
     When the string variable contains the entire message, that is, the message generation method has added the text “&lt;/PKG&gt;” to the string variable, the virtual machine  300  may then call a label generation method of the instance to generate a label (step  406 ) to associate with the exemplary message. In some cases, the label may be static and relate directly to the type of message, for instance, a registration request message may be defined to have a MSG attribute with value field containing “Registration Message”. In the case of the exemplary message, however, the label is dynamic. The virtual machine  300  may dynamically resolve the message attribute value field containing “Message To [SP.MAIL.TO]” to a label reading “Message To John Doe” based on the text entered by the user in the TO editbox. 
     The virtual machine  300  may then call a message record creation method of the instance to create (step  408 ) a message record. The message record may include the generated message and the label, among other data. The virtual machine  300  may then call a message record storage method to store (step  410 ) the message record in the queue table. Among the other data, the record creation method may include a time stamp in a Time Stamp field of the message record. 
     Concurrently, an instance of a message transmission object class (i.e. a message transmission object) may be arranging the transmission of the message portion of the oldest message record in the queue table to the transaction server  120 . The message transmission object may, for instance, determine which message record is the oldest in the queue table by considering a “time added” time stamp stored in each message record in the queue table. As such, the queue table may be considered to act as a First-In-First-Out (FIFO) queue in that the message transmission object attempts to transmit the message at the top of the queue, i.e., the message portion of the oldest message record, first. 
     Where the transmission of the message is successful, the message transmission object deletes the message record from the queue table and arranges the transmission of the message portion of the oldest message record in the queue table given that the former oldest message record has been deleted from the queue table. 
     Where the transmission of the message is unsuccessful, the message transmission object may delay re-attempting transmission of the message portion of the oldest message record in the queue table for a predetermined waiting time. Additionally, the message transmission object may store the time of the last attempt to transmit the message in a Last Attempt Time field associated with the Message field. The message transmission object may also read a value from a Transmission Attempt Number field associated with the Message field, increment the value by one and store the incremented value in the Transmission Attempt Number field. 
     Rather than delaying re-attempting transmission for a predetermined waiting time, the message transmission object may wait for a signal from the operating system of the mobile device  101 , where the signal indicates that communications to the network have been re-established. 
     At a subsequent time, the mobile device user may manipulate the input devices of the mobile device  101  to request to review the contents of the queue table. Upon receiving the request (step  502 ), an instance of a queue management object class (i.e. a queue management object) may then determine the contents of the queue table (step  504 ). That is, the queue management object may query the database in which is stored the queue table to determine which messages previously stored in the queue table have not yet been transmitted and, consequently, deleted from the queue table. For each message in a Message field in the queue table, the response to the database query may indicate the contents of the associated Time Stamp field, the contents of the associated Label field, the contents of the associated Last Attempt Time field and the contents of the associated Transmission Attempt Number field. 
     Where the exemplary message discussed above is in the queue table, the screen generation engine  306  may then present a screen (step  506 ) on the display  226  of the mobile device  101  in which screen the label “Message To John Doe” is presented representative of the exemplary message along with the time at which the message was stored in the queue table, the time of the last attempted transmission and the number of attempted transmissions. 
     The mobile device user may react to the screen by providing input (step  508 ). For instance, the user may request that the exemplary message, labeled “Message To John Doe”, be deleted from the queue table, say, if the exemplary message is deemed by the user to be out of date. Accordingly, the queue management object may delete the exemplary message from the queue table (step  510 ). Alternatively, the mobile device user may request that transmission of the messages in the queue table be re-attempted. The event handler  304  may then provide (step  512 ) the queue management object with a request to re-attempted transmission. Responsive to the request, the queue management object may re-attempt transmission of the oldest message in the queue table. 
     Notably, the exemplary message may not be the oldest message in the queue table and, as such, may not immediately benefit from the transmission re-attempt. However, where the mobile device  101  has returned into coverage range of a base station and the queue management object would otherwise continue delaying attempting retransmission until the expiry of the predetermined waiting time, the exemplary message may be transmitted sooner in the case of the request for a re-attempt at transmission than in the case of no such request. 
     The value field of the MSG attribute is evaluated at runtime, as are the other dynamic elements of the message. Notably, the value field of the MSG attribute is not transmitted to the transaction server  1   20  or to the backend application server  132  for use in an application. Indeed, the value field of the MSG attribute is used by the virtual machine  300  only when generating a display of queue table contents on the mobile device  101 . 
     Ideally, the label associated with messages of a predetermined type is sufficient to allow the user to understand the nature of the queued message so that the user may make a subsequent, informed decision. 
     Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.