U.S. patent application number 13/937385 was filed with the patent office on 2013-11-07 for device transfer of a server stored data item based on item id and determined nature of intended destination.
The applicant listed for this patent is Research In Motion Limited. Invention is credited to Gerhard Dietrich KLASSEN, Shaul S. Wisebourt.
Application Number | 20130297736 13/937385 |
Document ID | / |
Family ID | 38862826 |
Filed Date | 2013-11-07 |
United States Patent
Application |
20130297736 |
Kind Code |
A1 |
KLASSEN; Gerhard Dietrich ;
et al. |
November 7, 2013 |
Device Transfer of a Server Stored Data Item Based on Item ID and
Determined Nature of Intended Destination
Abstract
There is provided a method and system for communicating data
items about a communication network. An original data item for
communicating to a destination device is cached to a network data
store in association with unique ID (UID) generated to identify the
original data item. The UID is then sent as a proxy for the
original data item to the destination device. The original data
item may be processed (e.g. in response to a type of the
destination device) to create a processed data item and the
processed data item sent in place of the original data item. The
processed data item may also be cached in association with the UID,
for example, for reuse to eliminate duplicate processing. The
destination device is adapted to return the UID when further
communicating the original data item thereby to reduce
communication of the original data item about the communication
network.
Inventors: |
KLASSEN; Gerhard Dietrich;
(Waterloo, CA) ; Wisebourt; Shaul S.; (Waterloo,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Research In Motion Limited |
Waterloo |
|
CA |
|
|
Family ID: |
38862826 |
Appl. No.: |
13/937385 |
Filed: |
July 9, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11454840 |
Jun 19, 2006 |
8510471 |
|
|
13937385 |
|
|
|
|
Current U.S.
Class: |
709/217 |
Current CPC
Class: |
H04L 67/06 20130101;
G06F 16/9574 20190101; H04L 29/12066 20130101 |
Class at
Publication: |
709/217 |
International
Class: |
H04L 29/08 20060101
H04L029/08 |
Claims
1. A method of receiving data items, from a file processing system
in a communication network on behalf of a first device, at a second
device, the second device being coupled to the communication
network via the file processing system, the file processing system
being interposed between the first device and the second device,
the method comprising: the second device enabling the file
processing system to determine capabilities of the second device
for handling file types for the data items; when the second device
is not capable of handling a first file type for an original data
item intercepted by the file processing system during an original
communication sent by an originating device to the first device,
the second device receiving from the file processing system a
unique ID associated with the original data item, and an indication
of the first file type without the original data item; and when the
second device is capable of handling a second file type for the
original data item, the second device receiving from the file
processing system on behalf of the first device in completing a
subsequent communication either the original data item or a
processed data item according to the capabilities of the second
device; the file processing system having associated the unique ID
with the original data item, cached the original data item and the
unique ID, sent the unique ID and the original data item to the
first device in completing the original communication, received the
unique ID from the first device in the subsequent communication,
and having determined whether the data item is associated with the
first file type or the second file type in determining whether the
second device is capable of handling the original data item.
2. The method of claim 1, further comprising forwarding the unique
ID to another device that can process the original data item when
the second device is not capable of handling the first file
type.
3. The method of claim 1, further comprising processing the
original data item at the second device when the second device is
capable of handling the second file type.
4. The method of claim 1, further comprising sending another data
item to a new destination device via the file processing system to
have the file processing system generate a new unique ID for the
other data item to be provided to the new destination device for
further sending the other data item about the communication
network.
5. The method of claim 1, wherein the second device is a handheld
device.
6. The method of claim 1, wherein the second device is a desktop
computer.
7. A non-transitory computer readable medium comprising computer
executable instructions for receiving data items, from a file
processing system in a communication network on behalf of a first
device, at a second device, the second device being coupled to the
communication network via the file processing system, the file
processing system being interposed between the first device and the
second device, the computer executable instructions comprising
instructions for: the second device enabling the file processing
system to determine capabilities of the second device for handling
file types for the data items; when the second device is not
capable of handling a first file type for an original data item
intercepted by the file processing system during an original
communication sent by an originating device to the first device,
the second device receiving from the file processing system a
unique ID and an indication of the first file type without the
original data item; and when the second device is capable of
handling a second file type for the original data item, the second
device receiving from the file processing system on behalf of the
first device in completing a subsequent communication either the
original data item or a processed data item according to the
capabilities of the second device; the file processing system
having associated the unique ID with the original data item, cached
the original data item and the unique ID, sent the unique ID and
the original data item to the first device in completing the
original communication, received the unique ID from the first
device in the subsequent communication, and having determined
whether the data item is associated with the first file type or the
second file type in determining whether the second device is
capable of handling the original data item.
8. The non-transitory computer readable medium of claim 7, further
comprising instructions for forwarding the unique ID to another
device that can process the original data item when the second
device is not capable of handling the first file type.
9. The non-transitory computer readable medium of claim 7, further
comprising instructions for processing the original data item at
the second device when the second device is capable of handling the
second file type.
10. The non-transitory computer readable medium of claim 7, further
comprising instructions for sending another data item to a new
destination device via the file processing system to have the file
processing system generate a new unique ID for the other data item
to be provided to the new destination device for further sending
the other data item about the communication network.
11. The non-transitory computer readable medium of claim 7, wherein
the second device is a handheld device.
12. The non-transitory computer readable medium of claim 7, wherein
the second device is a desktop computer.
13. A second device configured for receiving data items, from a
file processing system in a communication network on behalf of a
first device, the second device being coupled to the communication
network via the file processing system, the file processing system
being interposed between the first device and the second device,
the second device comprising a communications subsystem for
communicating data items, a processor, and a memory storing
computer executable instructions and data to configure the second
device to: enable the file processing system to determine
capabilities of the second device for handling file types for the
data items; when the second device is not capable of handling a
first file type for an original data item intercepted by the file
processing system during an original communication sent by an
originating device to the first device, receive from the file
processing system a unique ID and an indication of the first file
type without the original data item; and when the second device is
capable of handling a second file type for the original data item,
receive from the file processing system on behalf of the first
device in completing a subsequent communication either the original
data item or a processed data item according to the capabilities of
the second device; the file processing system having associated the
unique ID with the original data item, cached the original data
item and the unique ID, sent the unique ID and the original data
item to the first device in completing the original communication,
received the unique ID from the first device in the subsequent
communication, and having determined whether the data item is
associated with the first file type or the second file type in
determining whether the second device is capable of handling the
original data item.
14. The second device of claim 13, further configured to forward
the unique ID to another device that can process the original data
item when the second device is not capable of handling the first
file type.
15. The second device of claim 13, further configured to process
the original data item at the second device when the second device
is capable of handling the second file type.
16. The second device of claim 13, further configured to send
another data item to a new destination device via the file
processing system to have the file processing system generate a new
unique ID for the other data item to be provided to the new
destination device for further sending the other data item about
the communication network.
17. The second device of claim 13, wherein the second device is a
handheld device.
18. The second device of claim 13, wherein the second device is a
desktop computer
Description
FIELD
[0001] The present application relates to electronic data
communications, in particular, communicating data items from one
data communications device to another via an intermediate
server.
BACKGROUND
[0002] Electronic data communications between users, such as
electronic mail (email), instant messaging (IM), short message
service (SMS) and the like is increasingly popular. Often, users
wish to communicate data items (i.e. files) to one another
including images, video or audio clips, text or word processing
documents, etc. However, some user devices such as handheld
electronic devices (e.g. mobile telephones, personal digital
assistants (PDAs), MP3 players, etc.) and particularly those
communicating via wireless communication networks are more
sensitive to resource limitations.
[0003] When developing software for such handheld devices, there
are a number of limitations that may be taken into consideration in
order to make handheld device operations fast and efficient.
Limited memory resources, communication bandwidth, and battery
power consumption is only a shortlist of issues handheld software
developers have to think about.
[0004] One of the solutions to reducing resource consumption is to
reduce the amount of data to be passed to and/or stored by the
handheld device. For example, image files may undergo processing or
conversion with a view to compressing the size of the image data.
Often such treatment reduces a quality of the image. Also it
demands image conversion every time the same image is
sent/forwarded to a handheld device providing an extra load on the
server executing the file processing. Another problem arises when
an image that was specifically converted for a handheld device gets
forwarded to a recipient (by e-mail, for example), who uses a
desktop communication device: the reduced quality image arrives
rather than the original image, although the recipient is capable
of viewing a better quality image.
[0005] A solution that addresses one or more of these issues is
therefore desired.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] In order that the subject matter may be readily understood,
embodiments are illustrated by way of examples in the accompanying
drawings, in which:
[0007] FIG. 1 is a block diagram which illustrates pertinent
components of a file processing system and handheld devices adapted
in accordance with an embodiment and an example message flow;
and
[0008] FIG. 2 is a flowchart of operations, in accordance with an
embodiment, to communicate a message including a file;
[0009] FIG. 3 is a flowchart of operations, in accordance with an
embodiment, to communicate a message including a unique ID
referencing a file;
[0010] FIG. 4 is a flowchart of operations, in accordance with an
embodiment, to process a file for a destination device; and
[0011] FIG. 5 is an example of a handheld device adapted in
accordance with an embodiment.
DETAILED DESCRIPTION
[0012] There is provided a method and system (among other aspects)
for communicating data items about a communication network. An
original data item for communicating to a destination device is
cached to a network data store in association with unique ID (UID)
generated to identify the original data item. The UID is then sent
as a proxy for the original data item to the destination device.
The original data item may be processed (e.g. in response to a type
of the destination device) to create a processed data item and the
processed data item sent in place of the original data item. The
processed data item may also be cached in association with the UID,
for example, for reuse to eliminate duplicate processing. The
destination device is adapted to return the UID when further
communicating the original data item thereby to reduce
communication of the original data item about the communication
network.
[0013] FIG. 1 illustrates pertinent components of an electronic
data communication system 100 for communicating data items such as
image, video and/or audio files (e.g. 120, 122 and 124) between
users of various electronic data communication devices (102, 104,
106 and 108) having varying processing, storing, displaying and/or
communicating capabilities as described below. In the illustrated
embodiment, a representative file processing system 110 is
interposed between the user devices 102, 104, 106 and 108 for
processing the data communications and data files.
[0014] Persons of skill in the art will appreciate that various
wireless and wired network infrastructure is not shown. For
example, devices 102 and 104 in the example of FIG. 1 comprise
"desktop" data communication devices such as PC's, laptops,
workstations, or other similar devices characterized by their
relatively powerful processors, plentiful storage and large screen
displays when compared to handheld devices 106 and 108. Desktop
devices 102 (desktop_1) and 104 (desktop_2) may be configured to
communicate with file processing system 110 via high speed networks
such as wired networks (LANs, WANs, public and/or private) that may
include short range wireless networks (e.g. Wi-Fi, etc.). Devices
102 and 104 may be coupled via emerging high speed wireless
networks such as satellite, microwave or other technology providing
high-bandwidth at relatively comparable costs to conventional wired
networks.
[0015] In contrast, handheld devices 106 and 108 comprise devices
such as cellular telephones, PDAs, etc. characterized by one or
more resource limitations or costs related to processor speed,
memory/storage size or latency, display size and network
communication speed or expense (e.g. charges per unit transmitted).
In the present embodiment, handheld devices 106 (handheld_1) and
108 (handheld_2) typically communicate with file processing system
110 via a data network which comprises one or more wireless
communication networks (GSM/GPRS, CDMA, 3G, etc.).
[0016] File processing system 110 comprises a computer server
coupled to a data store 112 configured to receive data
communications (messages) from a source for delivery to one or more
destinations. File processing system 110 may be a component in the
communication network that relays network traffic and is capable of
modifying packets based on application logic. The data
communications may include one or more data items or files. File
processing system 110 may process the files to generate processed
data items in response to the destination, such as to reduce file
size or convert to a compatible file type, etc. to meet the needs
of the destination or reduce bandwidth etc. as described.
Additionally, file processing system 110 may store the file (or any
file location if the file is available to the file processing
system via a network) and assign the file a unique ID (UID), which
UID is sent to the destination with the processed data item (file)
as applicable. Destinations not requiring processing of a file need
not receive the UID or a processed file.
[0017] File processing system 110 comprises one or more file
processors/converters 150, a UID generator 152, a destination
determiner 154 and send/receive mechanisms (e.g. queues) 156. File
processing system 110 is communicatively coupled to a cache 112
(e.g. a data store) for storing files (or file locations) from
messages (e.g. LF 120) and UIDs (e.g. UID_1 126 and UID_2 128) and,
optionally, processed files (e.g. SF_1 122 and SF_2 124). File
processing system 110 comprises a cache lookup and store module 160
for accessing cache data and a cache maintenance module 162 for
maintaining cache data, such as deleting stored files and/or UIDs
in accordance with a cache scheme. File processing systems further
comprises instructions and data implementing operations for file
processing, using the file processors/converters 150, UID generator
152, destination determiner 154, send/receive mechanisms 156 and
cache modules 60 and 162 described by way of examples further
below.
[0018] Destination devices receiving the forwarded message with a
UID in association with a processed file (e.g. handheld_1, 106 and
handheld_2, 108) may be adapted to comprise a UID handler 130 and
132 for handling the UIDs as described further herein below.
[0019] FIG. 1 further illustrates an example message flow among the
users of various electronic data communication devices (102, 104,
106 and 108). In the example, user of device 102 sends a message
Msg.sub.--1 including a large file LF 120 to two destinations,
namely the respective users of handheld_1 106 and handheld_2 108.
Msg.sub.--1 is routed via file processing system 110. File
processing system 110 receives the message via send/receive
mechanism 156 and analyzes Msg.sub.--1 to determine the processing
requirements for each of the destinations (106 and 108) using the
destination determiner 154. A cache lookup (160) may be performed
to see if LF was previously processed and cached with a processed
file required for a destination.
[0020] If LF 120 was previously stored with a processed file
required by the destination, the converted file may be returned
from the cache to reduce processing by file processing system 110.
In this example, LF 120 has not been stored before its receipt with
Msg 1.
[0021] For handheld_1 106, an appropriate file processor 150
creates SF_1 122 in response to LF. UID generator 152 generates a
first UID 126 for LF 120. LF 120 and optionally SF_1 122 are stored
to cache 112 via cache lookup/store 160. File processing system 110
routes a message, Msg 2, to handheld_1 106 comprising the message
of Msg 1 and SF_1 122 and UID_1 126.
[0022] File processing system 110 follows similar steps for the
remaining destination, namely handheld_2 108. SF_2 124 is generated
in response to the requirements of handheld_2 108. Persons of skill
in the art will understand that if the handhelds are of the same
type (i.e. have the same capabilities or requirements for file LF)
then SF_1 may be used rather than generating a second file SF_2. A
second UID, UID_2 128, is generated for LF and it and optionally
SF_2 are stored to cache 112. As LF 120 is already stored, it need
not be stored twice. A single common UID may be used for LF rather
than one per message. File processing system 110 generates
Msg.sub.--3 for handheld_2 108 including SF_2 124 and UID_2 128 and
communicates it via send/receive mechanisms 156.
[0023] In this example, the user of handheld_2 108 desires to send
LF to a user of desktop_2 (e.g. by forwarding Msg 3 or by other
means such as defining a new message and including file LF). The
user of handheld_2 may consider SF_2 124 to be LF 120
transparently. Handheld_2 and UID handler 132 cooperate to define a
message, Msg 4, including UID_2 as a proxy for LF 120 to send via
file processing system 110 for desktop_2 104. Sending only UID_2
saves network bandwidth and processing resource consumption by
various components in the network.
[0024] File processing system 110 receives Msg 4 and looks in cache
112 for LF 120 using UID_2. Destination determiner 154 determines
no processing is required for desktop_2 104. File processing system
110 defines a message, Msg 5 from Msg 4 and includes LF 120 from
the cache, sending it via mechanism 156.
[0025] File processing system cache 112 resources are limited and
there is a limit to the files that can be cached. Cache 112 can be
maintained via cache maintenance module 162. Cache 112 may be
cleared based on date information, or last access date, or on the
frequency of the file being forwarded, or any other low memory
management rule set. Optionally a user may be assigned a specific
amount cache storage space and files stored to the cache may be
stored in association with user information. Cache maintenance
schemes may be responsive to such user assigned space limits as
well.
[0026] FIG. 2 is a flowchart showing example operations 200 to
communicate a message received with a file.
[0027] At step 204, the message is received including a file,
File_In. The message also includes at least one destination. In
accordance with the present embodiment, steps 206-220 define a loop
for operations that are performed, as applicable, for each of the
destinations. Operations 200 end following a branch from step 206
once all destinations are handled. At step 208, the type of
destination D_Type is determined. Though not illustrated, a table
or other lookup using the destination address, for example, may be
used to determine a destination type.
[0028] Various levels of granularity may be implemented using
destination types. At a very course level, there are two D_Types,
one requiring processing of the file File_In and one not requiring
processing. In this case, only one type of processing may be
performed. Finer granularity may be useful to determine different
processing. In this way, all handhelds need not be treated equally.
For example, assume for a particular file type (e.g. PDF from
Adobe.RTM.) there are three D_Types: desktops (or unknown
destinations) may define one type requiring no processing; a first
group of handhelds with appropriate viewers define another type
requiring processing and a second group of handhelds with different
viewers define a further type requiring a different processing.
[0029] At step 210, a determination is made whether any processing
(i.e. a conversion such as compressing, flattening or changing from
one file type to another) is required for the D_Type. If not, via
step 212, a message is defined and sent to the destination
including the file received, File_In and operations loop to step
206.
[0030] If processing/converting is indicated at step 210 then at
step 214 File_in is processed in response to the D-Type to provide
a File_Out. As discussed below, if File_In was previously processed
for the D_Type and the processed file stored to the cache, File_Out
may be retrieved to avoid repeating the processing. A UID is
generated (step 216). At step 218, File_In and the UID are stored
to the cache. Optionally and as shown, the D_Type and File_Out are
also stored in association with the UID so that repetitious file
processing may be reduced. At step 220, a message is defined for
sending to the destination, including the UID and File_Out.
Operations 200 loop to step 206 for any further destinations.
[0031] FIG. 3 is a flowchart of operations 300, in accordance with
an embodiment, to communicate a message including a unique ID
referencing a file. Such messages are typically received from
handheld devices but may be for communicating to other handhelds or
desktops, etc.
[0032] At step 304, a message is received with a UID for
communicating to at least one destination. At step 305, a lookup of
the cache is performed to find the original file, File_In,
associated with the UID. Operations 306-320 define a loop for
execution, as applicable, for each destination. In the present
embodiment, operations 306-320 are the same as operations 206-220.
Accordingly, File_In is forwarded to the destination or processed,
as necessary for sending with a UID to the destination. Though not
illustrated, if at step 305 the lookup using UID fails to return an
original file (e.g. LF 120) an error may be returned to the source
of the message (e.g. handheld_1 106). The source device may be
configured (also not shown) to resend the message with or otherwise
provide the file (e.g. SF_1, as applicable) from a local store.
[0033] FIG. 4 is a flowchart of operations 400, in accordance with
an embodiment, to process a file for a destination device. At step
402, a cache lookup determines and returns the required processed
file (File_Out) for the destination type D_Type, if available. If
File_Out is available, operations 400 branch at step 404 to return
File_Out eliminating a repeated processing of File_In. If File_Out
is not available, via branch at step 404 to step 406, in response
to the D_Type step 406, particular processing (e.g. 408, 410 . . .
412) may be performed to generate File_Out before operations 400
end.
[0034] In certain situations, a destination device may not be able
to process a particular file type for a received file or it may be
otherwise desirable to not send the file or even a processed file
to the destination device (e.g. because it is too large). In
situations where the server (file processing system 110) knows the
destination device is not capable of handling a specific file type,
it may be advantageous to send a UID along with a file type to the
destination device, even without the file. The destination device
may be configured to determine how to handle the information (e.g.
display a stub icon in its place). The user of the destination
device can forward the original file (i.e. UID) to another
destination device that can process the file if desired. Thus,
operations discussed above may be adapted by a person of ordinary
skill in the art to send a UID even when the device cannot handle
the file type.
[0035] Accordingly, the solution described decreases the amount of
data transferred over wireless networks, especially when
communicating files from the handheld device. The solution also
seeks to address the issue of multiple conversions for the same
file. Original files and processed files may be server cached. The
solution also seeks to provide appropriate file quality for those
devices that are capable to use "full size" files as well as those
that require or otherwise desire to use lesser files.
[0036] As the UID is server generated and stored by the server and
device, there is no limit as to which file can be tagged with a UID
and shared by means of UID-based file transfer.
[0037] FIG. 5 is a detailed block diagram of a preferred handheld
device 502 adapted in accordance with an embodiment that may be
used as handheld_1 106 for example. Handheld device 502 is
preferably a two-way communication device having at least voice and
advanced data communication capabilities, including the capability
to communicate with other computer systems. Depending on the
functionality provided by handheld device 502, it may be referred
to as a data messaging device, a two-way pager, a cellular
telephone with data messaging capabilities, a wireless Internet
appliance, or a data communication device (with or without
telephony capabilities). Handheld device 502 may communicate with
any one of a plurality of base station transceiver systems (not
shown) within its geographic coverage area.
[0038] Handheld device 502 will normally incorporate a
communication subsystem 511, which includes a receiver 512, a
transmitter 514, and associated components, such as one or more
(preferably embedded or internal) antenna elements 516 and 518,
local oscillators (LOs) 513, and a processing module such as a
digital signal processor (DSP) 520. As will be apparent to those
skilled in field of communications, particular design of
communication subsystem 511 depends on the communication network in
which handheld device 502 is intended to operate.
[0039] Handheld device 502 may send and receive communication
signals over the network after required network registration or
activation procedures have been completed. Signals received by
antenna 516 through the network are input to receiver 512, which
may perform such common receiver functions as signal amplification,
frequency down conversion, filtering, channel selection, and like,
and in example shown in FIG. 5, analog-to-digital (A/D) conversion.
A/D conversion of a received signal allows more complex
communication functions such as demodulation and decoding to be
performed in DSP 520. In a similar manner, signals to be
transmitted are processed, including modulation and encoding, for
example, by DSP 520. These DSP-processed signals are input to
transmitter 514 for digital-to-analog (D/A) conversion, frequency
up conversion, filtering, amplification and transmission over
communication network via antenna 518. DSP 520 not only processes
communication signals, but also provides for receiver and
transmitter control. For example, the gains applied to
communication signals in receiver 512 and transmitter 514 may be
adaptively controlled through automatic gain control algorithms
implemented in DSP 520.
[0040] Network access is associated with a subscriber or user of
handheld device 502, and therefore handheld device 502 comprises a
memory module 562, such as a Subscriber Identity Module or "SIM"
card or a Removable User Identity Module (R-UIM), to be inserted in
or connected to an interface 564 in order to operate in the
network. Alternatively, memory module 562 may be a non-volatile
memory that is programmed with configuration data by a service
provider so that mobile station 502 may operate in the network.
Since handheld device 502 is a mobile battery-powered device, it
also includes a battery interface 554 for receiving one or more
rechargeable batteries 556. Such a battery 556 provides electrical
power to most if not all electrical circuitry in handheld device
502, and battery interface 254 provides for a mechanical and
electrical connection for it. The battery interface 554 is coupled
to a regulator (not shown in FIG. 5) that provides power V+ to all
of the circuitry.
[0041] Handheld device 502 includes a microprocessor 538 that
controls overall operation of mobile station 502. Communication
functions, including at least data and voice communications, are
performed through communication subsystem 511. Microprocessor 538
also interacts with additional device subsystems such as a display
522, a flash memory 524, a random access memory (RAM) 526,
auxiliary input/output (I/O) subsystems 528, a serial port 530, a
keyboard 532, a speaker 534, a microphone 536, a short-range
communications subsystem 540, and any other device subsystems
generally designated at 542. Some of the subsystems shown in FIG. 5
perform communication-related functions, whereas other subsystems
may provide "resident" or on-device functions. Notably, some
subsystems, such as keyboard 532 and display 522, for example, may
be used for both communication-related functions, such as entering
a text message for transmission over a communication network, and
device-resident functions such as a calculator or task list.
Operating system software used by microprocessor 538 is preferably
stored in a persistent store such as flash memory 524, which may
alternatively be a read-only memory (ROM) or similar storage
element (not shown). Those skilled in the art will appreciate that
the operating system, specific device applications, or parts
thereof, may be temporarily loaded into a volatile store such as
RAM 526.
[0042] Microprocessor 538, in addition to its operating system
functions, preferably enables execution of software applications on
handheld device 502. A predetermined set of applications that
control basic device operations, including at least data and voice
communication applications, will normally be installed on handheld
device 502 during its manufacture. A preferred application that may
be loaded onto handheld device 502 may be a personal information
manager (PIM) application having the ability to organize and manage
data items relating to user such as, but not limited to, e-mail,
calendar events, voice mails, appointments, and task items.
Naturally, one or more memory stores are available on handheld
device 502 and SIM 562 to facilitate storage of PIM data items and
other information.
[0043] The PIM application preferably has the ability to send and
receive data items via the wireless network. In a preferred
embodiment, PIM data items are seamlessly integrated, synchronized,
and updated via the wireless network, with the mobile station
user's corresponding data items stored and/or associated with a
host computer system thereby creating a mirrored host computer on
handheld device 502 with respect to such items. This is especially
advantageous where the host computer system is the mobile station
user's office or enterprise computer system. Additional
applications may also be loaded onto handheld device 502 through
network, an auxiliary I/O subsystem 528, serial port 530,
short-range communications subsystem 540, or any other suitable
subsystem 542, and installed by a user in RAM 526 or preferably a
non-volatile store (not shown) for execution by microprocessor 538.
Such flexibility in application installation increases the
functionality of handheld device 502 and may provide enhanced
on-device functions, communication-related functions, or both. For
example, secure communication applications may enable electronic
commerce functions and other such financial transactions to be
performed using handheld device 502.
[0044] In a data communication mode, a received signal such as a
text message, an e-mail message, or web page download will be
processed by communication subsystem 511 and input to
microprocessor 538. Microprocessor 238 will preferably further
process the signal for output to display 522 or alternatively to
auxiliary I/O device 528. A user of handheld device 502 may also
compose data items, such as e-mail messages, for example, using
keyboard 532 in conjunction with display 522 and possibly auxiliary
I/O device 528. Keyboard 532 is preferably a complete alphanumeric
keyboard and/or telephone-type keypad. These composed items may be
transmitted over a communication network through communication
subsystem 511.
[0045] For voice communications, the overall operation of handheld
device 502 is substantially similar, except that the received
signals would be output to speaker 254 and signals for transmission
would be generated by microphone 536. Alternative voice or audio
I/O subsystems, such as a voice message recording subsystem, may
also be implemented. Although voice or audio signal output is
preferably accomplished primarily through speaker 534, display 522
may also be used to provide an indication of the identity of a
calling party, duration of a voice call, or other voice call
related information, as some examples.
[0046] Serial port 530 in FIG. 5 is normally implemented in a
personal digital assistant (PDA)-type communication device for
which synchronization with a user's desktop computer is a
desirable, albeit optional, component. Serial port 530 enables a
user to set preferences through an external device or software
application and extends the capabilities of handheld device 502 by
providing for information or software downloads to handheld device
502 other than through a wireless communication network. The
alternate download path may, for example, be used to load an
encryption key onto handheld device 502 through a direct and thus
reliable and trusted connection to thereby provide secure device
communication.
[0047] Short-range communications subsystem 540 is an additional
optional component that provides for communication between handheld
device 502 and different systems or devices, which need not
necessarily be similar devices. For example, subsystem 540 may
include an infrared device and associated circuits and components,
or a Bluetooth.TM. communication module to provide for
communication with similarly enabled systems and devices.
Bluetooth.TM. is a registered trademark of Bluetooth SIG, Inc.
[0048] Handheld devices 502 may be adapted such as via software
(instructions and data) to handle UIDs as described above. A UID
received with a message may be persisted to the device (e.g. in
association with the message). When the message is forwarded to a
user, any received processed file may be omitted from the forwarded
message and the UID sent as a proxy for the original file. For
example, if the message received and to be forwarded is an email,
the UID may define as a header field of the email, a portion of the
body or as an attachment in accordance with email protocols. An
email application on handheld device 502 may be adapted to remove
the received processed file when forwarding the message.
[0049] Although embodiments have been described herein, it will be
understood by those skilled in the art that variations may be made
thereto without departing from their spirit or the scope of the
appended claims.
* * * * *