Patent Application
20080039051
The embodiment will be better understood with reference to the following Figures in which like numerals denote like parts and in which:
In one aspect there is provided a method of playing an audio file on a portable electronic device including receiving the audio file as an email attachment, sending a first request from an attachment viewer of the portable electronic device to an attachment server in order to determine a file type of the email attachment, building and storing a graph structure representing the audio file on the attachment server and sending a response to the attachment viewer notifying the attachment viewer of the file type of the email attachment, sending a second request from the attachment viewer to the attachment server to play the audio file, the request notifying the attachment server of a supported audio format of the portable electronic device and sending a transcoded audio file from the attachment server to the attachment viewer, the transcoded audio file corresponding to the audio file and having the supported audio format so that the transcoded audio file is playable by a media player of the portable electronic device.
In another aspect there is provided a portable electronic device including an attachment viewer application stored in flash memory of the portable electronic device, the attachment viewer for communicating with an attachment server to request conversion of an audio email attachment into an audio format supported by the portable electronic device; and a media player for playing a transcoded audio file returned from the attachment server, the transcoded file corresponding to the audio email attachment and having a format that is supported by the media player. A graph structure representing the audio file is built prior to the audio file being transcoded, the graph structure being stored on the attachment server.
Referring to
It will be appreciated that the portable electronic 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 or UMTS and broadband networks such as Bluetooth and variants of IEEE 802.11.
A server 18 handles wireless client requests from the portable electronic device 12. A firewall, or proxy server, 16, is provided between the server 18 and the Internet 14. The server 18 further operates as an attachment server, which communicates with an email client and an attachment viewer of the portable electronic 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 may alternatively be a separate server.
Referring now to
The portable electronic device 12 is based on a microcomputer including a processor 20 connected to a read-only-memory (ROM) 22 that contains a plurality of applications executable by the processor 20 that enables each portable electronic device 12 to perform certain functions including, for example, PIN message functions, SMS message functions and cellular telephone functions. ROM 22 is typically flash memory, however, other suitable types of ROM may alternatively be used. 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 non-volatile storage functions of the portable electronic device 12. The processor 20 receives input from various input devices including a keypad 28. The processor 20 outputs to various output devices including 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 40, which is generally a file storage system for the portable electronic device 12, is also provided.
The portable electronic device 12 includes an attachment viewer application that is stored in flash memory 22. The attachment viewer communicates with the server 18 so that audio or image email attachments may be converted to a format that is supported by the portable electronic device and then downloaded to the attachment viewer. By converting the audio attachments to a format that is supported by the portable electronic device 12, the portable electronic device 12 does not need to support multiple formats.
For image email attachments, the attachment server first builds a Document Object Model (DOM) by parsing the attachment file. In this manner, a graph structure is built within the server representing a map of the original image. The original image is then resized based on the image size limit of the portable electronic device, or the portable electronic device display size width and height (in pixels). The afore-mentioned DOM structure is disclosed in United States Patent Application No. 2006/0055693, which is herein incorporated by reference.
For audio attachments, device-side and server-side operations will be described with reference to
At step 45, the attachment viewer checks for streaming capability of the portable electronic device 12 using an Application Program Interface (API) call. If the portable electronic device 12 includes streaming capability, the method for playing audio files continues at step 46. If, however, the portable electronic device 12 does not include streaming capability, an error message stating that audio files are not supported is displayed, as indicated at step 47.
At step 46, the attachment viewer checks for the available Coders/Decoders (CODECs) on the portable electronic device 12 and selects the CODEC with the best compression in order to minimize bandwidth usage. The attachment viewer then makes a request to the attachment server 18 for audio data to be converted into a format that is based on the selected CODEC (step 48). Examples of destination formats include: a-Law, u-Law, MP3, GSM 610, AMR, Truespeech or other suitable formats. The original audio attachment may be any format that is embeddable within a .WAV file and includes a corresponding CODEC(s) on the attachment server 18.
At step 50, the attachment viewer receives initial audio data that has been converted from the attachment server 18. The audio data is streamed to the attachment viewer. The attachment viewer launches a media player to play the initial audio content and then checks for additional data, as indicated at steps 52 and 54. If there is additional data, the attachment viewer requests more data from the attachment server 18, as indicated at step 58. Alternatively, if there is no additional data available, the attachment viewer stops requesting audio data from the attachment server 18, as indicated at step 56.
Referring to
Audio DOM structure, which includes an audio component 80, is generally shown in
At step 64, which corresponds to step 48 of
If a cached audio component exists for the requested format, the attachment server 18 retrieves the cached audio component, as indicated at step 70. Alternatively, if the requested audio format is not already cached, the attachment server 18 traverses through the initial DOM that was built by the audio distiller and collects the original audio data, as indicated at step 72. The attachment server then transcodes the collected original audio data into the requested audio format and builds a new audio component from the transcoded audio data, as indicated at steps 74 and 76, respectively. Once built, the attachment server 18 caches the new audio component. The attachment server then encapsulates the audio data in Universal Content Stream (UCS) format and sends the UCS content to the attachment viewer, as indicated at step 78, which corresponds to step 50 of
The construction of the new audio component is similar to the construction of the original audio attachment DOM. The new audio component contains audio data corresponding to the original audio data, but usually consumes much less memory. In order to optimize performance, the attachment server 18 caches this new audio component together with the original DOM structure. Therefore, for the subsequent requests, audio data will be retrieved from the cache.
The method for playing audio files allows users to listen to audio attachments that are received by the portable electronic device 12 in email messages. This is useful for voicemail messaging services, for example, that automatically forward voicemail messages, which are recorded on a voicemail server, as audio attachments in email messages.
The method minimizes bandwidth utilization because the attachment server 18 transcodes the original uncompressed audio into the requested compressed format, and also re-samples the audio into speech quality. Further, the disclosed method minimizes the need for having multiple CODEC(s) on the portable electronic device. Even if the original audio format of the file is not supported, the attachment server 18 transcodes the original audio file into a format that is supported by the device platform, which results in significant reduction in cost.
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.
