Patent Publication Number: US-9418169-B2

Title: Extracting document data from multiple sources for display on a mobile communication device using HTTP request headers having XML strings therein

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority from U.S. Provisional Patent Application No. 61/251,507, filed Oct. 14, 2009. 
    
    
     FIELD 
     The present disclosure relates to mobile communication devices, and more particularly to a method and apparatus for extracting document data from multiple sources for display on a mobile communication device irrespective of the source of the document. 
     BACKGROUND 
     It is known in the wireless communication arts to download and display documents from a mail server using an attachment viewer application on a mobile communication device, such as a Personal Digital Assistant (PDA) or smart phone, where the documents are received as attachments to email messages. Each attachment is provided with a filename and is linked to an email message in a known manner. Often, a single email message may contain multiple attachments. It is also known in the art to download and view documents from a web server using a mobile device browser, or from other sources (e.g. calendar application, instant messenger (IM), etc.) However, there are differences in how the attachment viewer functions to present such documents on the mobile communication device depending on the sources of such documents. 
     For example, when downloading documents from a mail server it is known to send a request for ‘chunks’ of document data from an attachment server along with an XML command descriptor string, and to receive from the server successive binary chunks of document data along with an XML response string. By way of contrast, a mobile device attachment viewer browser plug-in does not issue requests for ‘chunks’ of document data, and receives a stream of document data from the server without any accompanying XML string. 
     Also, document data is downloaded to the attachment viewer for email attachments in constant, relatively small, chunk sizes (e.g. 16 KB) for documents and images (e.g. 64 KB), such that attachments always have the same number of data chunks for a specified chunk size, which enables a series of display features (e.g. hyperlink jump in a document, random worksheet selection, text server find, etc.), and results in quick storing and processing of the small chunk sizes. On the other hand, the attachment viewer browser plug-in receives a stream of document data that is typically limited to a larger chunk size (e.g. up to 256 Kb), resulting in a truncated version of the entire document. Partial parsing and loading is used in this case to speed up data parsing and display. 
     Furthermore, the attachment viewer for emails can be characterized by a persistence model that allows saving binary data chunks and the information received in the attachment server XML responses, thereby minimizing the need for additional document requests in the event the same attachment is subsequently viewed again. According to this persistence model, the binary data chunks may be compressed (e.g. to approx. 30% of the original size) and can be backed up and restored. On the other hand, the attachment viewer for the browser does not store any binary document data since the received stream of data chunks is cached by the browser (e.g. without any compression or any XML response information from the server). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The embodiments will be better understood with reference to the following Figures in which like numerals denote like parts and in which: 
         FIG. 1  is a schematic diagram of a wireless communication system that includes a mobile communication device, a proxy server and an attachment server; 
         FIG. 2  is a block diagram of components of the mobile communication device according to an embodiment; and 
         FIG. 3  is a unified modeling language (UML) diagram showing communication between an invoking application, attachment viewer and the attachment server of the communication system of  FIG. 1  for downloading data to the mobile communication device; 
         FIG. 4  is a class diagram of an attachment viewer of the mobile communication device, according to an embodiment; 
         FIG. 5  is a unified modeling language (UML) diagram showing communication between a browser, attachment viewer and the attachment server of the communication system of  FIG. 1  for downloading data to the mobile communication device; 
         FIG. 6  is a flowchart showing server-side operation of a method for downloading data to an attachment viewer of the mobile communication device; 
         FIG. 7  is a flowchart showing steps of an exemplary method implemented by the mobile communication device; 
         FIG. 8  is a flowchart showing steps of an exemplary method implemented by the proxy server; and 
         FIG. 9  is a flowchart showing steps of an exemplary method implemented by the attachment server. 
     
    
    
     DETAILED DESCRIPTION 
     A method and apparatus are set forth herein for uniform presentation of documents on a mobile communication device irrespective of the source of the document (e.g. whether the source is an attachment server for email attachments, a web server, an IM server, etc.) 
     According to one aspect set forth in this specification, there is provided a method operable on a mobile communication device, comprising opening a browser session and issuing an HTTP request for document data, said request having an XML descriptor added to headers of the HTTP request for identifying the request and said document data; and receiving an HTTP response including said XML descriptor along with document binary data representing respective chunks of said document data for display on said mobile communication device. 
     According to another aspect there is provided a method operable on a proxy server, comprising receiving an HTTP request for document data, said request having an XML descriptor added to headers of the HTTP request for identifying the request and said document data; searching for said XML descriptor in the headers of the HTTP request and in response to locating said XML descriptor determining that the request is a request for an attachment and issuing a request for the attachment; and receiving an XML response and document binary data, said XML response including said XML descriptor, packaging the XML descriptor in response HTTP headers and transmitting the response and document binary data. 
     According to a further aspect there is provided a method operable on an attachment server, comprising receiving a GET HTTP request for an attachment, said GET HTTP request including an XML descriptor in the HTTP headers thereof; and transmitting an XML response and document binary data representing at least one chunk of said attachment, said XML response including said XML descriptor. 
     Referring to  FIG. 1 , a communication system  10  for a mobile communication device  12  is generally shown. The mobile communication device  12  is operable to effect communications over a radio communications channel and communicates with a base station (not shown) while located within a coverage area that is defined by the base station. The base station is part of a wireless network that is in communication with the Internet  14 , or other network such as a WAN. Data is delivered to the mobile communication device  12  via wireless transmission from the base station. Similarly, data is sent from the mobile communication device  12  via wireless transmission to the base station. 
     It will be appreciated that the mobile communication device  12  is movable within the coverage area and can be moved to coverage areas defined by other base stations. Further, as will be understood by one of ordinary skill in the art, wireless networks include GSM/GPRS, CDPD, TDMA, iDEN, Mobitex, DataTAC networks, EDGE, EVDO or UMTS and broadband networks such as Bluetooth and variants of 802.11. 
     A proxy server  16  handles client requests from the mobile communication device  12  for documents stored within an attachment server  18 . The attachment server  18  communicates with the proxy server  16  to transmit attachments such as documents, spreadsheets, images, multimedia files, etc. for viewing via an attachment viewer of the mobile communication device  12  to allow a user to view attachments that are received in email messages. While only one server  18  is shown for illustration purposes, a person skilled in the art will understand that the attachment server  18  may alternatively be a network of attachment servers. Sources for the attachments stored within server  18  may include a web server  15 , mail server  19 , IM server  17 , etc. Preferably the document data is downloaded to mobile communication device  12  in chunks of binary data in an attachment viewer readable format, for example Universal Content Stream (UCS) format. 
     One aspect of this specification addresses methods and apparatus implemented on the mobile communication device  12  and another aspect of this specification addresses methods and apparatus implemented on the proxy server  16  for uniform presentation of documents on the device  12 . 
     Referring now to  FIG. 2 , a block diagram of certain components within the mobile communication device  12  is shown. In the present embodiment, the mobile communication device  12  is based on the computing environment and functionality of a wireless personal digital assistant (PDA). It will be understood, however, that the mobile communication device  12  is not limited to wireless personal digital assistants. Other mobile communication devices are possible, such as smart telephones, and laptop computers. 
     The mobile communication device  12  includes a processor  20  connected to a read-only-memory (ROM)  22  that contains a plurality of applications executable by the processor  20  that enables the mobile communication device  12  to perform certain functions including, for example, instant messaging (IM), calendaring, email messaging, web browsing and cellular telephony, and includes an attachment viewer for viewing documents received from the attachment server  18 , web server  15  and IM server  17 . 
     As discussed in greater detail below, the attachment viewer includes a user interface to accept user actions when viewing documents from the web browser, instant messaging application (e.g. to enhance image for specific resolution, view embedded object, switch to text/image, etc). 
     Also as discussed below, a common architecture is defined for attachment viewer invocation from different applications (e.g. calendar, browser, instant messenger, messaging application, etc.), and an attachment viewer callback interface is provided for the application that invokes the attachment viewer to be notified when user actions are selected. 
     The processor  20  is also connected to a random access memory unit (RAM)  24  and a persistent storage device  26 , which are responsible for various storage functions of the mobile communication device  12 . The processor  20  receives input from input devices such as a keypad  28  and trackball  29  (or other input device such as a touchpad, touch screen, etc.) The processor  20  outputs to various output devices, such as an LCD display  30 . A microphone  32  and phone speaker  34  are connected to the processor  20  for cellular telephone functions. The processor  20  is also connected to a modem and radio device  36 . The modem and radio device  36  is used to connect to wireless networks and transmit and receive voice and data communications through an antenna  38 . A content store  39 , which is generally a file storage system for the mobile communication device  12 , is also provided. 
     As shown in the UML diagram of  FIG. 3  upon receipt of a user request  40  for a document, the calling application  41  uses ( 42 ) an attachment viewer display engine  43  which in turn uses the persistent store  26  to display and store content from attachment server  18 . Requests for content data are made by the proxy server  16  to attachment server  18  by passing an XML string in the body of the request, as discussed in greater detail below with reference to  FIGS. 5 and 6 . In the event that the server response string indicates that the document has been stored in cache memory (e.g. persistent storage  26 ), there is no need to download the document from the original URL location. 
     As discussed in greater detail below, the attachment viewer includes a user interface, which accepts user actions ( 42 ) for enhanced image data request, retrieval of an embedded object or the textual data for rendered slides/pages, etc. 
     Turning to the class diagram of  FIG. 4 , in conjunction with  FIG. 3 , if the document data is not found in the persistent store  26 , the attachment viewer  45  public classes are used to issue the command or request ( 44 ) for the initial document data chunk (e.g. a More command or a RequestMore command issued by interfaces  46  and  47 , respectively). A viewer callback interface  48  is provided for the invoking application  41  to be notified when user actions are selected. Attachment viewer meta-data is maintained and passed to the notified object for inclusion in subsequent requests to the proxy server  16 . This provides the invoking application  41  with the ability to issue new data and update the display  30 . Interface  48  uses attachment viewer response mechanism  49  to process responses from the attachment server  18 . However, alternative configurations are possible, for example if the calling application  41  (e.g. browser) is actually invoked only after the initial data has been retrieved from the attachment server  18 . In this case it is the proxy server  16  that issues the initial data request. 
     The attachment viewer display engine  43  is invoked using a plug-in to the calling application. Application specific implementations of the persistence and transport interfaces  46 ,  47  and  50 , are passed to the display engine  43  using rendering options of the plug-in architecture. Display engine  43  renders the existing data in a consistent manner, makes data requests based on user input and is notified when data is received from the server to update the display  30 . 
     While the MoreTransport interface implementations  46  or  47  are optional, the PersistOperation ( 50 ) must be valid when the display field is constructed, otherwise no data can be displayed. However, it is not required that the persistence store  26  exist. For example, the persistent store can be session based and constructed in memory when document data chunks for a linked document are displayed (e.g. in the browser). 
     PersistOperation implementation ensures that document data received from attachment server  18  via the available transport  46  or  47  is cached and retrieved in a similar manner and that the display engine  43  retrieves the data in a unified way. There are three generic keys used in accessing an atomic attachment in the persistent store  26  (int or long—message id for email, int or long—more part id for email, and archive indicator—string indicating the archive index for a document in an archive). These values are used to initialize the display engine  43  and can have a different meaning for each calling application (e.g. a hash code for the downloaded url) or can be generic (except for the archive indicator which has a predefined meaning). These values are also used to route a received data response to the active display engine  43  displaying the particular document. 
     MoreTransport implementation provides the mechanism for sending a request for data to the attachment server  18 . The transport media can be email MORE, HTTP request etc. Common constraints for the MoreTransport implementation include that it accept and transport to the attachment server  18  an XML string descriptor and that it is able to receive an XML descriptor from the attachment server together with the binary data chunk. 
     DocViewUCSConverter  52  is a class used by the attachment viewer  45  in an embodiment, to register when the device  12  boots (i.e. starts or resets) so that it understands the MIME type “UCS”. Thus, every binary data with this MIME type (a file with extension ucs or binary data in memory coming from a data connection with UCS MIME type) is routed through the attachment viewer architecture. 
     In addition to configuring the attachment viewer for uniform presentation of documents, as discussed above with reference to  FIGS. 3 and 4 , the invoking application  41  must also be appropriately configured. For example, where the invoking application  41  is a browser a listener interface should be implemented for communicating with callback interface  48 , and the browser should be configured to make appropriate HTTP requests to the proxy server  16  (i.e. by constructing a request header, setting cmd, etc). When the server response has been received, the browser is configured to pass the data to the attachment viewer and update the display  30  (i.e. a referrer parameter is notified via DocView Notification classes  49 ). This ‘referrer’ is an intermediate class connected with the document viewer display classes  43 . Likewise, where the invoking application  41  is an instant messaging application, a listener interface should also be implemented and the IM application should be configured to make appropriate IM requests to the proxy server  16  (i.e. by setting IM fields, etc). Also, where the invoking application  41  is an email client the aforenoted listening interface is used and the client is configured to make the appropriate emails requests to the proxy server  16 . 
     Turning now to  FIGS. 5 and 6 , operation of the proxy server  16  is described for downloading attachment server supported files using the device browser. In response to selection of a linked document  61 , the browser uses  51  the proxy server  16  to download ( 63 ) the document from the attachment server  18 . More particularly, proxy server  16  analyses the linked file extension and provided that the document is of a type that is supported by the attachment server  18 , issues a command to the attachment server  18 . The command may be a generic initial attachment server request ( 53 ), or may use the XML descriptor in the HTTP headers to download the document from the attachment server  18 . The proxy server  16  preferably issues the command to the server  18  after adding an MD5 encryption hash function, Origin Key, and XML tags, etc. 
     This functionality is implemented in the attachment viewer  45  by allowing it to open a browser channel ( 55 ) for document data communication and thereby make data requests ( 57 ). 
     If the requested document is of a type that is supported by attachment server  18 , the resulting XML response and binary document data are sent back ( 67 ) to the device browser  45  via HTTP. The metadata information contains the initial XML attachment server response, as well. The XML response string is part of the HTTP headers for the particular request and it is accessible using a predefined property. The binary document data is sent to the device using a predefined content type (e.g. Universal Content Stream (UCS)). 
     The attachment viewer  43  detects this content type and is able to display ( 69 ) the initial data by using the input XML string and the binary data. The attachment viewer  45  sends such requests based on user input by adding the XML string to the HTTP headers property and issuing a GET HTTP request using the document download url. Proxy server  16  searches for the specific property in the HTTP request header and, if encountered, determines that the request is an attachment server request. Upon receiving the response from attachment server  18 , proxy server  16  packages the XML descriptor in the http headers and sends it back to the device  12  together with the response binary document data. It should be noted that the XML string descriptor is not always the same; it is manipulated by attachment viewer  45  and server  16  by adhering to a predefined protocol. A correspondence between the initial proxy request and the attachment server ip address should be in place in order to access the attachment server cache for subsequent requests from the device  12 , and thereby eliminate the need for multiple downloads of the linked document from the web server  15 . 
     In response to execution of an action ( 71 ) using the interface ( 46 ), such as to download an embedded object, view slides text, enhance image, etc.), the attachment viewer creates ( 73 ) an XML string and adds the document ID to it (e.g. full url, attachment server IP address, etc.) as well as fields for identifying the request for the attachment server  18 , sends ( 75 ) the request to the proxy server  16 , and awaits response from the proxy server  16 . The proxy server  16  adjusts the attachment server response to create a response XML string. 
     The following is an example XML string sent to the attachment viewer  45  upon the initial download of the linked document and display in the browser (note that the XML tags set forth below may not, in practice, be exactly as indicated (for example, extra tags are set forth and the &lt;SIP&gt; and &lt;URL&gt; tags are processed by proxy server  16  but never reach the attachment viewer  45 ): 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CR&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;FT&gt;0.4&lt;/FT&gt; // file type as returned by the attachment server 
               
            
           
           
               
               
            
               
                   
                 to the MDS as response to the NEXT command 
               
            
           
           
               
               
            
               
                   
                 &lt;URL&gt;document url&lt;/URL&gt; // document full path 
               
               
                   
                 &lt;SIP&gt;10.144.10.45&lt;/SIP&gt; // used attachment server ip address 
               
            
           
           
               
               
            
               
                   
                 &lt;/CR&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example XML request added by the attachment viewer  45  to the HTTP request for the case of retrieving an embedded object: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CD&gt;NEXT&lt;/CD&gt; 
               
               
                   
                 &lt;CP&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;999&lt;/PARTIDX&gt; // Full Content part index 
               
               
                   
                 &lt;DOMID&gt;i0\i99&lt;/DOMID&gt; // unique dom ID for the embedded 
               
               
                   
                 object 
               
               
                   
                 &lt;URL&gt;document url&lt;/URL&gt; // document full path 
               
               
                   
                 &lt;SIP&gt;10.144.10.45&lt;/SIP&gt; // attachment server ip address to use 
               
            
           
           
               
               
            
               
                   
                 &lt;/CP&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example response XML string retrieved from the HTTP response: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CR&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;999&lt;/PARTIDX&gt; // requested part index 
               
               
                   
                 &lt;DOMID&gt;i0\i99&lt;/DOMID&gt; // unique dom ID for the embedded 
               
               
                   
                 object 
               
               
                   
                 &lt;ERRNO&gt;0&lt;/ERRNO&gt; // 0 if no error, error value otherwise 
               
               
                   
                 &lt;URL&gt;document url&lt;/URL&gt; // document full path 
               
               
                   
                 &lt;SIP&gt;10.144.10.45&lt;/SIP&gt; // attachment server ip address used 
               
            
           
           
               
               
            
               
                   
                 &lt;/CR&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example XML request sent by the attachment viewer  45  for enhancing a slide/page: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CD&gt;RENDER&lt;/CD&gt; 
               
               
                   
                 &lt;CP&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;1003&lt;/PARTIDX&gt; // request part index for 
               
               
                   
                 enhance 
               
               
                   
                 &lt;SArDOMID&gt;i0&lt;/SArDOMID&gt; // slide/page dom ID to 
               
               
                   
                 enhance 
               
               
                   
                 &lt;DI&gt;853x640x16&lt;/DI&gt; // desired pixel size and color depth 
               
            
           
           
               
               
            
               
                   
                 after enhance operation 
               
            
           
           
               
               
            
               
                   
                 &lt;IRD&gt;0x0x960x720&lt;/IRD&gt; // desired rectangle to be enhanced 
               
            
           
           
               
               
            
               
                   
                 (source coordinates) 
               
            
           
           
               
               
            
               
                   
                 &lt;URL&gt;document url&lt;/URL&gt; // document full path 
               
               
                   
                 &lt;SIP&gt;10.144.10.45&lt;/SIP&gt; // attachment server ip address to use 
               
            
           
           
               
               
            
               
                   
                 &lt;/CP&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example response XML string: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CR&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;1003&lt;/PARTIDX&gt; // enhance part index 
               
               
                   
                 &lt;IRD&gt;0x0x960x720&lt;/IRD&gt; // page rectangle enhanced in 
               
            
           
           
               
               
            
               
                   
                 source coordinates 
               
            
           
           
               
               
            
               
                   
                 &lt;ERRNO&gt;0&lt;/ERRNO&gt; // 0 if no error, error value otherwise 
               
               
                   
                 &lt;SArDOMIDs&gt;i0,&lt;/SArDOMIDs&gt; // slide domID for which the 
               
            
           
           
               
               
            
               
                   
                 requested response is for 
               
               
                   
                 &lt;/CR&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example XML request for text of a ppt/pdf document that has already been rendered: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CD&gt;NEXT&lt;/CD&gt; 
               
               
                   
                 &lt;CP&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;999&lt;/PARTIDX&gt; // request Full Content for main 
               
               
                   
                 document 
               
            
           
           
               
               
            
               
                   
                 &lt;/CP&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     The following is an example response XML string: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;BBASCMD&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;CR&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;PARTIDX&gt;999&lt;/PARTIDX&gt; // Full Content part index 
               
               
                   
                 &lt;ERRNO&gt;0&lt;/ERRNO&gt; // 0 if no error, error value otherwise 
               
            
           
           
               
               
            
               
                   
                 &lt;/CR&gt; 
               
            
           
           
               
            
               
                 &lt;/BBASCMD&gt; 
               
               
                   
               
            
           
         
       
     
     From the foregoing, it will be understood that three methods are implemented by the mobile communication device  12 , proxy server  16  and attachment server  18 , respectively. 
     A method implemented by mobile communication device  12  is illustrated in  FIG. 7 , and includes opening a browser session with proxy server  16  and issuing an HTTP request for document data ( 77 ), wherein the request includes an XML descriptor added to headers of the HTTP request for identifying the request and the document data being requested, receiving an HTTP response ( 79 ) from proxy server  16  that includes the XML descriptor and document binary data representing respective chunks of the document data, and displaying at least one chunk of document data on the mobile communication device  12 . 
     A method implemented by proxy server  16  is illustrated in  FIG. 8 , and includes receiving the HTTP request ( 83 ) from mobile communication device  12 , searching for the XML descriptor in the HTTP headers ( 85 ) and, if located then issuing a request ( 87 ) to attachment server  18  for downloading the attachment. 
     A method implemented by attachment server  18  is illustrated in  FIG. 9 , and includes receiving ( 89 ) the attachment request including an XML descriptor from proxy server  16 , and transmitting an XML response ( 91 ) to the proxy server  16  along with document binary data representing at least one chunk of attachment, wherein the XML response includes the XML descriptor. 
     Additional implementation aspects are as follows: 
     The web server  15  preferably populates HTTP responses with attachment viewer meta-data (i.e. ip used, url, etc) obtained from the attachment server  18 , and accepts attachment viewer meta-data if present in the HTTP request header. (i.e. server ip to use, part, dom id, etc) and passes this information to the attachment server  18 . 
     IM server  17  is configured to support responding with attachment server meta-data by accepting attachment server meta-data and using it during transcoding (i.e. server ip, part, dom id, etc). 
     Other device application modifications may be implemented, as follows: 
     A File Explorer application on the device  12  may be configured to provide a “View” verb in the display menu if the file extension matches one of a plurality of supported file extensions (doc, xls, pdf etc.) When the “View” menu item is selected, the File Explorer application or a plug-in contacts the proxy server  16  in a similar way as the browser plug-in in order to create a transmission channel, whereupon the attachment server  18  converts the file to a viewer-readable format (e.g. UCS) for downloading to the device  12  via proxy server  16 . The attachment viewer  45  is preferably invoked immediately after the document data starts to be downloaded. It will be understood that the attachment viewer application  45  registers itself as a File Explorer plug-in for the viewer-readable format (e.g. UCS). 
     As discussed above, the persistence model for the attachment viewer plug-in to the mobile device browser is configured so as not to rely on the initial data cached by the browser and to generate only the minimum number of wireless requests required for viewing a previously downloaded document. Also, by aligning the functionality of the attachment viewer  45  for both email and browser document viewing, additional advantages may be realized such as the document data chunks being part of low memory manager implementation on the device  12  and the ability to backup and restore document data. 
     A specific embodiment has been shown and described herein. However, modifications and variations may occur to those skilled in the art. All such modifications and variations are believed to be within the sphere and scope of the present embodiment.